home *** CD-ROM | disk | FTP | other *** search
/ IRIX Installation Tools & Overlays 2001 November / SGI IRIX Installation Tools & Overlays 2001 November - Disc 3.iso / relnotes / performer_eoe / ch5.z / ch5
Text File  |  2001-10-10  |  164KB  |  3,895 lines
  1.  
  2.  
  3.  
  4.                                   - 1 -
  5.  
  6.  
  7.  
  8.        6.  _C_h_a_n_g_e_s__f_r_o_m__P_r_e_v_i_o_u_s__R_e_l_e_a_s_e_s
  9.  
  10.        This Chapter identifies incremental changes and enhancements
  11.        since IRIS Performer 2.0.  Changes are presented in reverse
  12.        chronological order, with the most recent releases listed
  13.        first.
  14.  
  15.  
  16.        6.1  _C_h_a_n_g_e_s__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._4_._2
  17.  
  18.        6.1.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._4_._2
  19.  
  20.           +o Multiple pfHyperpipe()/DPLEX groups experienced timing
  21.             delays between pfFrame() and the Channel DRAW Callback.
  22.             This was due to Performer not synchronizing timing
  23.             between hyperpipe groups.  This has been fixed (SCR
  24.             815415).
  25.  
  26.           +o Added support for anisotropic textures in .pfa files.
  27.             They were previously only supported in the .pfb files.
  28.             This has been fixed (SCR 818183).
  29.  
  30.           +o Enabling CPU stats was causing Performer on Linux to
  31.             core dump.  This has been fixed (SCR 820725).
  32.  
  33.           +o Fixed precision issues in pfVolFog with aligning pixel
  34.             copy and polygons covering patchy fog area (no SCR
  35.             number).
  36.  
  37.  
  38.        6.2  _C_h_a_n_g_e_s__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._4_._1
  39.  
  40.        6.2.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._4_._1
  41.  
  42.           +o Intersection testing was limited to geosets with fewer
  43.             than 2^16 triangles.  This limit has been increased to
  44.             2^32 (no SCR number).
  45.  
  46.           +o A successful intersection with an indexed triangle
  47.             strip geoset did not fill the 'prim' field of pfHit.
  48.             This has been fixed (SCR 816478).
  49.  
  50.           +o Intersections and picking with an off-axis viewing
  51.             frustum was not functional.  This has been fixed, in
  52.             both the 2.4.1 and 2.2.12 versions (SCR 803898).
  53.  
  54.           +o Intersection testing with pfDoubleDCS, pfDoubleSCS, or
  55.             pfDoubleFCS nodes was not implemented in Performer 2.4.
  56.             A limited fix has been made, in which single-precision
  57.             versions of the matrices are used for the intersection
  58.             test (no SCR number).
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.                                   - 2 -
  71.  
  72.  
  73.  
  74.           +o DSO IVERSION identifiers specified by Performer had an
  75.             invalid format, sgiX.Y.ABC.  The proper format is
  76.             sgiX.Y.  This could cause applications using the
  77.             backwards-compatibility libraries to fail and has been
  78.             fixed (SCR 816478).
  79.  
  80.           +o Calling pfGetChanESky() before defining a pfEarthSky
  81.             could cause a crash.  This has been fixed (no SCR
  82.             number).
  83.  
  84.           +o Calling pfGetCurLights() before defining any lights
  85.             could cause a crash.  This has been fixed (no SCR
  86.             number).
  87.  
  88.  
  89.        6.2.2  _N_e_w__f_e_a_t_u_r_e_s__a_n_d__i_m_p_r_o_v_e_m_e_n_t_s__i_n__2_._4_._1
  90.  
  91.        6.2.2.1  _p_f_V_o_l_F_o_g
  92.        OpenGL Performer 2.4.1 extends the algorithm for rendering
  93.        layered fog by incorporating self-shadowing and scene
  94.        shadowing. The lower parts of a dense fog or objects below a
  95.        dense fog then appear darker.
  96.  
  97.        Self-shadowing is enabled by setting flag 0x40 to 1.  The
  98.        fog mode should be set to PFVFOG_EXP.  If the fog has
  99.        different colors at different elevations and the flag 0x0100
  100.        is set to 1 a secondary scattering of light is approximated.
  101.        In this case the color of higher layers may affect the color
  102.        of lower layers.  If the flag 0x80 is set the scene objects
  103.        below a dense fog become darker.  In all these effects the
  104.        light is assumed to come from the top.
  105.  
  106.  
  107.        6.3  _D_i_f_f_e_r_e_n_c_e_s _b_e_t_w_e_e_n _O_p_e_n_G_L _P_e_r_f_o_r_m_e_r _2._4 _a_n_d _I_R_I_S
  108.             _P_e_r_f_o_r_m_e_r _2._2
  109.  
  110.  
  111.  
  112.        6.3.1  _B_e_h_a_v_i_o_r_/_A_P_I__c_h_a_n_g_e_s
  113.  
  114.  
  115.        6.3.1.1  _I_R_I_S__G_L
  116.        OpenGL Performer 2.4 supports OpenGL-based rendering only.
  117.        IRIS GL is no longer supported.  Accordingly, the library
  118.        DSO naming scheme has been changed.  What was previously
  119.        _l_i_b_p_f__o_g_l._s_o (for example) is now simply _l_i_b_p_f._s_o.  Be
  120.        certain to update your Makefiles.
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.                                   - 3 -
  137.  
  138.  
  139.  
  140.        6.3.1.2  _p_f_d_u_._h__s_t_r_u_c_t_u_r_e_s_:__p_f_d_G_e_o_m_,__p_f_d_P_r_i_m
  141.        OpenGL Performer 2.4 changes the structure of pfdPrim and
  142.        pfdGeom in order to support multi-texture. Existing code
  143.        using the prior version of these structures must be ported.
  144.        The struct elements tbind, texCoords, texCoordList,
  145.        itexCoords are now arrays of size PF_MAX_TEXTURES.
  146.  
  147.        Porting existing code, the struct members tbind, texCoords,
  148.        texCoordList, itexCoords should be replaced by tbind[0],
  149.        texCoords[0], texCoordList[0], itexCoords[0].
  150.  
  151.        When initializing a pfdPrim struct or when creating a
  152.        pfdGeom struct without the function pfdNewGeom, one must
  153.        initialize the entire array tbind[] to PFGS_OFF as in the
  154.        code example:
  155.  
  156.            {{{{
  157.                iiiinnnntttt        tttt;;;;
  158.                ppppffffddddPPPPrrrriiiimmmm    ****pppp;;;; ////**** OOOOrrrr:::: ppppffffddddGGGGeeeeoooommmm ****pppp;;;; ****////
  159.  
  160.                ffffoooorrrr ((((tttt ==== 0000 ;;;; tttt <<<< PPPPFFFF____MMMMAAAAXXXX____TTTTEEEEXXXXTTTTUUUURRRREEEESSSS ;;;; tttt ++++++++))))
  161.                    pppp---->>>>ttttbbbbiiiinnnndddd[[[[tttt]]]] ==== PPPPFFFFGGGGSSSS____OOOOFFFFFFFF;;;;
  162.            }}}}
  163.  
  164.        6.3.1.3  _p_f_F_l_u_x__d_e_f_a_u_l_t__n_u_m_b_e_r__o_f__b_u_f_f_e_r_s_.
  165.        OpenGL Performer 2.4 counts a DBASE process as a pfFlux
  166.        client. Forking a DBASE process increases the default number
  167.        of buffers on a pfFlux by one. Previous versions of OpenGL
  168.        Performer ignored the DBASE process when computing the
  169.        default number of pfFlux buffers.
  170.  
  171.  
  172.        6.3.2  _N_e_w__f_e_a_t_u_r_e_s__a_n_d__i_m_p_r_o_v_e_m_e_n_t_s__i_n__2_._4
  173.  
  174.        6.3.2.1  _E_n_h_a_n_c_e_m_e_n_t_s__t_o__t_h_e__b_a_s_e__l_i_b_r_a_r_y
  175.        OpenGL Performer 2.4 introduces many architectural
  176.        improvements to core features in the library, avoiding API
  177.        changes so as to ensure that very little porting effort will
  178.        be required.  These include:
  179.  
  180.           +o Multipipe scalability enhancements.  A significant
  181.             per-pipe overhead in pfFrame() has been removed. This
  182.             enables making many per-frame scene graph changes even
  183.             when using a high number of graphics pipes.
  184.  
  185.           +o Cliptexture performance enhancements.  The texture
  186.             download algorithm has been enhanced to significantly
  187.             improve texture download speed and the accuracy of DTR
  188.             performance.  Refer to
  189.             /usr/share/Performer/src/sample/C++/clipdemo for an
  190.             example.
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.                                   - 4 -
  203.  
  204.  
  205.  
  206.           +o Ability to lock multiple processes on the same
  207.             processor. Avoids deadlocks that used to occur in some
  208.             priority configurations.
  209.  
  210.           +o Light-point process enhancements.
  211.  
  212.           +o pfFlux is enhanced.  More detailed explanation has been
  213.             added to the Programmer's Guide.
  214.  
  215.           +o Refer to the detailed notes in the 2.2.x section for
  216.             other enhancements since the 2.2 release.
  217.  
  218.  
  219.        6.3.2.2  _E_n_h_a_n_c_e_m_e_n_t_s__t_o__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__f_o_r__L_i_n_u_x
  220.        Because both the IRIX and Linux versions of OpenGL Performer
  221.        share a common code base and API, as enhancements and new
  222.        features are introduced in the IRIX version, they
  223.        simultaneously become available in Linux, and vice versa.
  224.        In addition many internal enhancements have been made in
  225.        OpenGL Performer for Linux to bring its core functionality
  226.        ever closer to that available in IRIX.  Some of the
  227.        enhancements _s_p_e_c_i_f_i_c to OpenGL Performer 2.4 for Linux
  228.        include:
  229.  
  230.           +o Multi-process operation (pfMultiprocess, pfMultithread)
  231.  
  232.           +o Frame-accurate timing control (pfPhase)
  233.  
  234.           +o Anisotropic Texture filtering
  235.  
  236.           +o Multi-Texture support
  237.  
  238.           +o Many performance & feature optimizations, including
  239.             several specific to SGI Linux Desktop workstations.
  240.        These are described in more detail below.
  241.  
  242.  
  243.        6.3.2.3  _N_e_w__f_e_a_t_u_r_e_s__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._4
  244.        OpenGL Performer 2.4 includes revolutionary new support for
  245.        sophisticated model shading, enabling users to render higher
  246.        quality scenes far more easily than coding in OpenGL
  247.        directly.  This release also provides several advanced
  248.        visual effects, to better support simulation applications.
  249.        The new features include:
  250.  
  251.  
  252.        6.3.2.3.1  _p_f_S_h_a_d_e_r
  253.        pfShader is a new approach to dramatically simplify OpenGL
  254.        multi-pass rendering creation.  Instead of writing direct
  255.        OpenGL code using pfDraw callbacks and draw bins, users can
  256.        take advantage of the easy to use OpenGL Shader to create
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.                                   - 5 -
  269.  
  270.  
  271.  
  272.        the same effects at modeling time.
  273.  
  274.        OpenGL Shader is a powerful appearance-modeling tool.  Using
  275.        the Shader language and compiler, users can easily create
  276.        shaders that describe very sophisticated multi-pass
  277.        rendering effects. Read http://www.sgi.com/software/shader/
  278.        for details on OpenGL Shader. The shaders can be associated
  279.        with any pfNode in the OpenGL Performer scene graph to
  280.        achieve high performance multi-passing rendering results
  281.        using OpenGL Performer without writing OpenGL code directly.
  282.  
  283.        pfShader in 2.4 is our first effort at supporting OpenGL
  284.        Shader within OpenGL Performer. The purpose is to establish
  285.        the architecture foundation for this revolutionary approach.
  286.        There are still many limitations in the pfShader.  Not all
  287.        shaders created from OpenGL Shader can be supported in 2.4,
  288.        for example, shaders with variable changes.  Further
  289.        extensions and performance enhancements will become
  290.        available in future regular releases.
  291.  
  292.        Man pages to see: pfShader, pfShaderManager
  293.  
  294.        Sample programs to check out:
  295.  
  296.                /usr/share/Performer/src/pguide/libpf/C++/shader_blue_and_purple.C
  297.                /usr/share/Performer/src/pguide/libpf/C++/shader_multiple_shaders.C
  298.                /usr/share/Performer/src/pguide/libpf/C++/shader_multiple_shaders.C
  299.                /usr/share/Performer/src/pguide/libpf/C++/shader_red_material.C
  300.                /usr/share/Performer/src/pguide/libpf/C++/shader_test.C
  301.                /usr/share/Performer/src/pguide/libpf/C++/shader_wood_texture.C
  302.  
  303.        Utilities to use:
  304.  
  305.                /usr/share/Performer/src/tools/ipf2pf (convert
  306.        shader file into pfShader file)
  307.                /usr/share/Performer/src/lib/libpfdb/libpfpfs
  308.                /usr/share/Performer/src/lib/libpfdb/libpfpfb
  309.  
  310.        Documentation to use in addtion to Programmer's Guide:
  311.                /usr/share/Performer/src/tools/pfshader_file_spec.txt
  312.  
  313.        pfShader Data:
  314.  
  315.                /usr/share/Performer/data/shaderExample.pfb
  316.                /usr/share/Performer/data/shaders/*.shader
  317.  
  318.  
  319.        6.3.2.3.2  _M_u_l_t_i-_p_r_o_c_e_s_s _o_p_e_r_a_t_i_o_n _i_n _L_i_n_u_x (_F_U_L_L _E_D_I_T_I_O_N
  320.        _o_n_l_y)
  321.        OpenGL Performer 2.4 for Linux now supports the complete
  322.        App/Cull/Draw/Isect/Compute/Dbase/Input multiprocessing
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.                                   - 6 -
  335.  
  336.  
  337.  
  338.        capabilities of OpenGL Performer for IRIX.  Likewise, the
  339.        underlying IRIX shared arena, locks, and IPC management
  340.        routines such as ussetlock(), usunsetlock() are available
  341.        for developer application through /usr/include/ulocks.h.
  342.  
  343.  
  344.        6.3.2.3.3  _F_r_a_m_e_-_a_c_c_u_r_a_t_e__t_i_m_i_n_g__c_o_n_t_r_o_l__i_n__L_i_n_u_x
  345.        OpenGL Performer 2.4 for Linux now supports the complete
  346.        FREE_RUN/LIMIT/FLOAT/LOCK pfPhase() functionality of OpenGL
  347.        Performer for IRIX.  Note that phase control is currently
  348.        implemented as an emulation timing layer which does not yet
  349.        support swapbuffer synchronization to the vertical retrace;
  350.        If your graphics card currently supports synchronization to
  351.        vertical retrace, Phase control may be off by one video
  352.        field.  This will be corrected as OpenGL driver improvements
  353.        allow.
  354.  
  355.  
  356.        6.3.2.3.4  _M_u_l_t_i_-_t_e_x_t_u_r_e
  357.        OpenGL Performer 2.4 supports the application of multiple
  358.        texture maps on a single polygon using the OpenGL multi-
  359.        texture extension.  Currently, this feature is only
  360.        available in OpenGL Performer for Linux.  pfGeoSet now
  361.        accepts multiple texture coordinate arrays, and pfGeoState
  362.        now accepts multiple pfTexture, pfTexGen, pfTexLOD, texture
  363.        matrices and detail textures.  The API additions are very
  364.        straightforward.
  365.  
  366.        Man pages to see: pfGeoSet, pfGeoState
  367.  
  368.        Sample programs to check out:
  369.  
  370.                /usr/share/Performer/src/pguide/libpf/C/multiTexBox.c
  371.                /usr/share/Performer/src/pguide/libpf/C/multiTexBox_flux.c
  372.  
  373.        Utilities to use:
  374.  
  375.                /usr/share/Performer/src/lib/libpfdu/pfdBuilder.c
  376.                /usr/share/Performer/src/lib/libpfdu/pfdTMesher.c
  377.                /usr/share/Performer/src/lib/libpfutil/hash.c
  378.                /usr/share/Performer/src/lib/libpfdu/pfdGeoBuilder.c
  379.                /usr/share/Performer/src/lib/libpfdu/pfdRebuild.c
  380.  
  381.        Loaders that support multi-texture data: Flight loader, pfb
  382.        loader
  383.  
  384.  
  385.        6.3.2.3.5  _A_n_i_s_o_t_r_o_p_i_c__f_i_l_t_e_r
  386.        Standard mipmap filtering can induce blurring on a texture
  387.        if the texture is applied to a polygon which is angled away
  388.        from the viewer.  To reduce this blurring, an anisotropic
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.                                   - 7 -
  401.  
  402.  
  403.  
  404.        filter can be used to improve visual quality.  The
  405.        anisotropic filter is only available on Linux systems.
  406.  
  407.        Man pages to see: pfTexture
  408.  
  409.        Sample programs to check out:
  410.  
  411.                /usr/share/Performer/src/pguide/libpf/C/anisotropic.c
  412.                /usr/share/Performer/src/pguide/libpf/C++/anisotropic.C
  413.  
  414.  
  415.        6.3.2.3.6  _V_o_l_u_m_e__f_o_g
  416.        pfVolFog is a new class that uses a multi-pass algorithm to
  417.        draw the scene with fog that has different densities at
  418.        different locations. It extends the basic layered fog
  419.        provided by pfEarthSky and it supports two types of fog:
  420.        layered fog and patchy fog.
  421.  
  422.        Layered fog changes only with elevation, its density and
  423.        color is uniform at a given height. It is defined by a set
  424.        of elevation points, each specifying a fog density and
  425.        optionally also a fog color at the point's elevation.  The
  426.        density and the color between two neighboring points is
  427.        linearly interpolated.  Patchy fog has a constant density in
  428.        a given area. The boundaries of this area can be defined by
  429.        an arbitrary three-dimensional object or a set of objects.
  430.  
  431.        Man pages to see: pfVolFog
  432.  
  433.        Demos to check out:
  434.  
  435.                /usr/share/Performer/src/sample/C++/volfog
  436.                /usr/share/Performer/src/sample/C/fogfly
  437.  
  438.  
  439.        6.3.2.3.7  _R_o_t_o_r__W_a_s_h
  440.        A pfRotorwash is used to create a graph including geometry
  441.        and pfState which represents the visual downwash effect on
  442.        terrain or water. The geometry changes dynamically with the
  443.        scene and position from which it is generated. Users who are
  444.        developing helicopter demos are especially encouraged to try
  445.        out this feature.
  446.  
  447.        Man pages to see: pfRotorwash
  448.  
  449.        Demos to check out:
  450.  
  451.                /usr/share/Performer/src/sample/C++/rotorwash
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.                                   - 8 -
  467.  
  468.  
  469.  
  470.        6.3.2.3.8  _D_o_u_b_l_e__p_r_e_c_i_s_i_o_n__m_a_t_r_i_x__s_u_p_p_o_r_t  Double precision
  471.        matrix operations are supported in this release. This
  472.        feature is extremely helpful when rendering large databases
  473.        where objects can be very far away from the origin.
  474.  
  475.        Man pages to see: pfDoubleDCS, pfDoubleFCS, pfDoubleSCS
  476.  
  477.        Sample programs to check out:
  478.  
  479.                /usr/share/Performer/src/pguide/libpf/C/doubleDCS.c
  480.                /usr/share/Performer/src/pguide/libpf/C/doubleDCS2.c
  481.  
  482.        Demos to check out:
  483.  
  484.                /usr/share/Performer/src/sample/C/clipfly
  485.  
  486.  
  487.        6.3.2.3.9  _A_b_i_l_i_t_y _t_o _l_o_c_k _m_u_l_t_i_p_l_e _p_r_o_c_e_s_s_e_s _o_n _t_h_e _s_a_m_e
  488.        _p_r_o_c_e_s_s_o_r.  OpenGL Performer 2.4 adds new API for
  489.        eliminating frame glitches when locking multiple processes
  490.        on one processor. This API enables a temporary priority
  491.        upgrade for low priority processes when the APP process
  492.        waits for them.
  493.  
  494.        Man pages to see: pfProcessPriorityUpgrade,
  495.        pfProcessHighestPriority
  496.  
  497.  
  498.        6.3.2.3.10  _D_P_L_E_X__s_u_p_p_o_r_t
  499.        Refer to the description under 2.2.4 for details.
  500.  
  501.  
  502.        6.3.2.3.11  _L_O_D__e_v_a_l_u_a_t_i_o_n__f_u_n_c_t_i_o_n
  503.        pfLOD is extended to take a user function for picking an LOD
  504.        result. The result of this user function is a floating point
  505.        number. This gives users ultimate flexibility in LOD
  506.        evaluation.
  507.  
  508.        Man pages to see: pfLOD
  509.  
  510.  
  511.        6.4  _D_i_f_f_e_r_e_n_c_e__b_e_t_w_e_e_e_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._3__a_n_d__2_._2
  512.  
  513.        IRIS Performer 2.3 was the first release of Performer for
  514.        Linux.  Please refer to the OpenGL Performer website for
  515.        details.
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.                                   - 9 -
  533.  
  534.  
  535.  
  536.        6.5  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._1_0
  537.  
  538.        6.5.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._1_0
  539.  
  540.           +o The IRIX PFB file loader was unable to read PFB files
  541.             generated on Linux-based systems due to file
  542.             endianness.  This has been fixed (SCR 786258).
  543.  
  544.           +o Performer serialized the rendering of each pfPipe on
  545.             multi-pipe systems running in "Multi-Keyboard" or "TKO"
  546.             mode.  This has been fixed (SCR 791376).
  547.  
  548.  
  549.        6.6  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._9
  550.  
  551.        6.6.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._9
  552.  
  553.           +o Calligraphic light points flash in certain multipipe
  554.             configurations.  This is the case even in
  555.             PF_LPOINT_BOARD emulation mode.
  556.  
  557.             Each calligraphic board (including the simulated one)
  558.             has some amount of memory which is used to specify
  559.             light points. When performer fills up this memory
  560.             buffer, meaning that the board can not take more input,
  561.             it will render the remaining points in software mode.
  562.             lpoints rendered in software mode occupy more pixels on
  563.             screen than lpoints rendered in hardware mode, hence
  564.             the flashing behavior. The problem is due to the fact
  565.             that Performer's memory book-keeping for lpoint buffers
  566.             breaks under a couple conditions:
  567.  
  568.             1) When at least one pipe is doing calligraphics but
  569.             pipe 0 is not 2) When calligraphics are used on non-
  570.             consecutive pipes
  571.  
  572.             These memory book-keeping problems have been fixed in
  573.             2.2.9 (SCR 787645).
  574.  
  575.  
  576.  
  577.        6.7  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._8
  578.  
  579.        6.7.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._8
  580.  
  581.           +o Access into Shared Memory pages is slow the first time
  582.             each page is accessed.  This is particularly noticeable
  583.             when paging ClipTextures.  A workaround has been
  584.             implemented (see 'New Features' below).  SCR 606004.
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.                                   - 10 -
  599.  
  600.  
  601.  
  602.           +o pfFindNode/pfLookupNode cannot find a pfGeode with
  603.             pfNode type, though the manpage says that Performer
  604.             uses pfIsOfType instead of pfIsExactType for those
  605.             functions.  This has been fixed so that
  606.             pfNode/pfLookupNode use pfIsOfType instead of
  607.             pfIsExactType semantics (SCR 774905).
  608.  
  609.           +o
  610.  
  611.           +o The pfb loader leaks memory when a texture image file
  612.             is not available. Loading and deleting a model with one
  613.             texture image file missing leaks sizeof(pfTexture)
  614.             bytes.
  615.  
  616.  
  617.        6.7.2  _N_e_w__f_e_a_t_u_r_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._8
  618.  
  619.        6.7.2.1  _A_r_e_n_a__P_a_g_e__E_x_e_r_c_i_s_i_n_g
  620.  
  621.           +o When a forked process accesses memory in the shared
  622.             arena, the first time it accesses each page is much
  623.             slower than accessing that page subsequently. This
  624.             problem becomes very pronounced when the forked process
  625.             is striding through a large number of pages, such as
  626.             sending large amounts of texture from the arena to the
  627.             pipes, as is the case with cliptexturing.  In this
  628.             case, the application will experience performance
  629.             glitches when memory regions are accessed for the first
  630.             time.
  631.  
  632.             The workaround for this problem is to access a memory
  633.             location in each page of the arena during program
  634.             startup. This workaround makes most sense in the DRAW
  635.             process, since it's the one that's affected most due to
  636.             its access of large amounts of texture data.
  637.  
  638.             Performer 2.2.8 will touch each arena page in each draw
  639.             process if the environment variable
  640.             "_PFDRAW_EXERCISE_ARENA" is set. If the environment
  641.             variable is set to a numerical value, each draw process
  642.             will run through the arena the specified number of
  643.             times, reporting how long it took to touch all the
  644.             pages in each iteration. It's not necessary to touch
  645.             each page more than once except to see the difference
  646.             in access times to those pages.
  647.  
  648.  
  649.        6.7.2.2  _S_u_p_p_o_r_t__f_o_r__n_e_w__O_c_t_a_n_e__g_r_a_p_h_i_c_s__h_a_r_d_w_a_r_e
  650.  
  651.           +o Performer 2.2.8 introduces support for the new Octane
  652.             graphics hardware. If this hardware is detected,
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.                                   - 11 -
  665.  
  666.  
  667.  
  668.             Performer will use OpenGL features that are on the fast
  669.             path for this system, just as with other supported
  670.             hardware.
  671.  
  672.  
  673.        6.7.2.3  _P_o_s_t__l_p_o_i_n_t_-_d_r_a_w__c_a_l_l_b_a_c_k
  674.  
  675.           +o Some applications need to draw to the frame buffer
  676.             after all other drawing has occurred. In the case where
  677.             applications uses a forked LPOINT process, the drawing
  678.             of light points happens after the draw callback is
  679.             invoked, making it difficult to draw something on top
  680.             of the light points.
  681.  
  682.             To get around this problem, Performer 2.2.8 now
  683.             supports a post-lpoint-draw callback on pfChannels. To
  684.             add such a callback to a pfChannel, use the
  685.             "PFTRAV_POSTLPOINT" token to pfChannel::setTravFunc or
  686.             pfChanTravFunc, for example:
  687.  
  688.  
  689.             cccchhhhaaaannnnnnnneeeellll---->>>>sssseeeettttTTTTrrrraaaavvvvFFFFuuuunnnncccc((((PPPPFFFFTTTTRRRRAAAAVVVV____PPPPOOOOSSSSTTTTLLLLPPPPOOOOIIIINNNNTTTT,,,, ppppoooossssttttDDDDrrrraaaawwwwFFFFuuuunnnncccc))));;;;
  690.  
  691.             The callback will be invoked regardless of
  692.             multiprocessing mode. In applications which fork the
  693.             LPOINT process, it will be called after the last light
  694.             point has been drawn in each channel. In applications
  695.             which do not fork the LPOINT process, the post-lpoint-
  696.             draw callback will be invoked immediately after the
  697.             draw callback returns. This callback is not reflected
  698.             in the stats.
  699.  
  700.             Since Performer 2.2.8 is an eoe update, we can not
  701.             distribute header files, so to use the FTRAV_POSTLPOINT
  702.             token, you must define it. Include the following lines
  703.             in files using the token:
  704.  
  705.  
  706.             ####iiiiffffnnnnddddeeeeffff PPPPFFFFTTTTRRRRAAAAVVVV____PPPPOOOOSSSSTTTTLLLLPPPPOOOOIIIINNNNTTTT
  707.             ####ddddeeeeffffiiiinnnneeee PPPPFFFFTTTTRRRRAAAAVVVV____PPPPOOOOSSSSTTTTLLLLPPPPOOOOIIIINNNNTTTT 6666
  708.             ####eeeennnnddddiiiiffff
  709.  
  710.        6.8  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._7
  711.  
  712.        6.8.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._7
  713.  
  714.           +o Triangle fans were not being correctly reported by the
  715.             stats.  This has been fixed (SCR 769104).
  716.  
  717.           +o An array bounds underrun in _pfCuller::pf_applyXform
  718.             could lead to memory corruption.  This has been fixed
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730.                                   - 12 -
  731.  
  732.  
  733.  
  734.             (SCR 767432).
  735.  
  736.           +o The prototype for pfDTRApplyImageCache was incorrectly
  737.             documented.  This has been fixed (SCR 752840).
  738.  
  739.           +o pfNode::bufferClone could cause a segmentation
  740.             violation.  This has been fixed (SCR 695725).
  741.  
  742.           +o The channel frustum type was being reset by
  743.             pfChannel::pf_cullShadows.  This has been fixed (SCR
  744.             679085).
  745.  
  746.           +o A memory leak caused by multi-pipe pfImageCache
  747.             invalidation has been fixed.
  748.  
  749.  
  750.        6.9  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._6
  751.  
  752.        6.9.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._6
  753.  
  754.           +o A change in the semantics of sginap() could cause
  755.             frames to be missed if the application was running in
  756.             FLOAT or LOCK phase and finishing its frame more than a
  757.             full video field early.  See Chapter 4 of these release
  758.             notes for more details.  This has been fixed in IRIX
  759.             6.5.5 (SCR 635983).
  760.  
  761.           +o A math error when in multipass lighting mode caused
  762.             infinite lights (those with a w coordinate of 0) to be
  763.             transformed incorrectly through the modelview matrix,
  764.             producing incorrect lighting results.  This has been
  765.             fixed.
  766.  
  767.           +o A reversed cross product caused the
  768.             pfLightSource::setSpotDir call to rotate the light in
  769.             the wrong direction in some cases.  This has been
  770.             fixed.
  771.  
  772.        6.9.2  _N_e_w__f_e_a_t_u_r_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._6
  773.  
  774.        6.9.2.1  _M_u_l_t_i_p_a_s_s__L_i_g_h_t_i_n_g
  775.  
  776.           +o The multipass implementation introduced in 2.2.5 did
  777.             not support fog-based range attenuation of projective
  778.             lights.  This feature is now supported.
  779.  
  780.           +o Prior releases cleared the color buffer to red when
  781.             generating the shadow maps for shadow-casting lights.
  782.             Code which assumed that the shadowmap generation pass
  783.             would clear the framebuffer to black produced incorrect
  784.             results, so this behavior has been changed; The color
  785.  
  786.  
  787.  
  788.  
  789.  
  790.  
  791.  
  792.  
  793.  
  794.  
  795.  
  796.                                   - 13 -
  797.  
  798.  
  799.  
  800.             buffer is now cleared to black when rendering the
  801.             shadow map.  Note:  No assumptions should be made about
  802.             the contents of the color buffer between shadowmap and
  803.             scene rendering; always clear the color buffer when
  804.             unsure of its contents.
  805.  
  806.  
  807.        6.10  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._5
  808.  
  809.        6.10.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._5
  810.  
  811.           +o pfFrustum::makeOrtho() calculated incorrect near/far
  812.             clip plane values.  This has been fixed (SCR 658920).
  813.  
  814.           +o pfGetStage() could return incorrect values due to the
  815.             Performer clock being included in the process list.
  816.             This has been fixed (SCR 668773).
  817.  
  818.           +o Channel-CULL callbacks registered from the .ct loader
  819.             could collide when used in multi-channel
  820.             configurations, resulting in the incorrect calculations
  821.             of texture coordinates.  This regression has been fixed
  822.             (SCR 668222).
  823.  
  824.           +o perfly, asdfly, and clipfly could not configure multi-
  825.             hyperpipe systems.  This capability has been added (SCR
  826.             675711).
  827.  
  828.           +o Draw statistics were only being accumulated for the
  829.             first pipe in a hyperpipe group.  This has been fixed
  830.             (SCR 675517).
  831.  
  832.           +o A garbage frame would sometimes be seen when using
  833.             texture from a DIVO source in Performer on Onyx2
  834.             systems with 'Reality' graphics.  This was due to a
  835.             mismatch in Performer's automatic detection of graphics
  836.             type and has been fixed (SCR 671095).
  837.  
  838.           +o The default displacement offset for coplanar polygons
  839.             was set too large for small frusta.  This has been
  840.             fixed (SCR 625598, 670200).  See below for
  841.             configuration details.
  842.  
  843.           +o Several additional improvements to the multipass
  844.             algorithm used for projective texture pfLightSources
  845.             have been made in 2.2.5.  In particular, the algorithm
  846.             now supports geometry with texture based transparency
  847.             (for example, a tree billboard).
  848.  
  849.  
  850.  
  851.  
  852.  
  853.  
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862.                                   - 14 -
  863.  
  864.  
  865.  
  866.        6.10.2  _N_e_w__f_e_a_t_u_r_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._5
  867.  
  868.        6.10.2.1  _S_u_p_p_o_r_t__f_o_r__O_p_e_n_G_L__1_._1__g_l_P_o_l_y_g_o_n_O_f_f_s_e_t_(_)
  869.  
  870.        This release modifies the routines used for coplanar polygon
  871.        displacement to one based upon the polygon offset
  872.        functionality in OpenGL 1.1.  The changes apply to all
  873.        platforms using OpenGL 1.1 except the Impact series.
  874.  
  875.        Users may revert to the prior (Performer 2.2) behavior by
  876.        setting the environment variable
  877.        PF_FORCE_EXT_POLYGON_OFFSET.
  878.  
  879.        Likewise, users may choose to force the new functionality to
  880.        be used on Impact systems (despite known bugs at this time)
  881.        by setting the environment variable
  882.        PF_FORCE_ARB_POLYGON_OFFSET.
  883.  
  884.        In case the results of the new offset behavior are not ideal
  885.        for a particular system or database, users may tune the
  886.        values set internally by IRIS Performer.  The environment
  887.        variables PF_ARB_POLYGON_OFFSET_FACTOR and
  888.        PF_ARB_POLYGON_OFFSET_UNITS can be set to floating point
  889.        values which will then be used internally as arguments to
  890.        glPolygonOffset().  See the glPolygonOffset(3G) man page for
  891.        further details of the effect of these settings.
  892.  
  893.        Although the OpenGL 1.1 glPolygonOffset() changes were
  894.        intended to resolve machine dependency issues, please note
  895.        that the ideal offset factor and units value may still vary
  896.        from system to system.  The glPolygonOffset() values set by
  897.        IRIS Performer were chosen for typical database settings on
  898.        InfiniteReality systems and may require adjustment on other
  899.        OpenGL 1.1 systems, using the environment variables
  900.        described above.
  901.  
  902.  
  903.        6.11  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._4
  904.  
  905.        6.11.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._4
  906.  
  907.           +o The Performer signal handler would enter an infinite
  908.             loop if a process forked or sproc'd from the APP
  909.             process exited.  This has been fixed (SCR 651566).
  910.  
  911.           +o Setting the PF_LPOINT_BOARD environment variable to
  912.             enable emulation of calligraphic hardware (by using
  913.             standard raster light points) had no effect.  This has
  914.             been fixed (SCR 615443).
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.                                   - 15 -
  929.  
  930.  
  931.  
  932.           +o Threading the lightpoint process caused a segmentation
  933.             fault.  This has been fixed.
  934.  
  935.           +o Models containing pfLightPoints with a NULL
  936.             pfLPointState could cause a segmentation violation on
  937.             O2 systems running IRIX 6.5.2.  This has been fixed
  938.             (SCR 614274).
  939.  
  940.           +o Several improvements to the multipass algorithm used
  941.             for projective texture pfLightSources have been made.
  942.             Colored spotlights now interact correctly with each
  943.             other.  Note that the current algorithm does not
  944.             support geometry with texture based transparency (for
  945.             example, a tree billboard), and can only produce
  946.             translucent geometry on systems with multisampling
  947.             capability.
  948.  
  949.           +o Several pfStats::query() tokens were unimplemented.
  950.             Most of the missing tokens can now be used to query
  951.             statistics.  The following will still return an error:
  952.  
  953.                +o PFSTATSVAL_CPU_SECS
  954.                  PFSTATSVAL_CPU_GFX_SWAPBUFFERS
  955.                  PFSTATSVAL_GFXPIPE_TIMES_PERCENTAGE
  956.                  PFSTATSVAL_GFXPIPE_TIMES_PERCENTAGE_HOST
  957.                  PFSTATSVAL_GFXPIPE_TIMES_PERCENTAGE_XFORM
  958.                  PFSTATSVAL_GFXPIPE_TIMES_PERCENTAGE_FILL
  959.                  PFSTATSVAL_GFXPIPE_TIMES_SECS
  960.                  PFSTATSVAL_GFXPIPE_TIMES_SECS_HOST
  961.                  PFSTATSVAL_GFXPIPE_TIMES_SECS_XFORM
  962.                  PFSTATSVAL_GFXPIPE_TIMES_SECS_FILL
  963.  
  964.           +o IRIX 6.5 introduced support for the concurrent use of
  965.             shared arenas and POSIX threads (pthreads), however
  966.             there was an error in the GLX implementation which
  967.             prevented IRIS Performer applications from opening a
  968.             window if the pthread library was linked.  The GLX
  969.             implementation in the IRIX 6.5.3 overlay has addressed
  970.             this problem, so IRIS Performer applications can now be
  971.             safely used with pthreads.
  972.  
  973.           +o The CSB loader has been updated to enable the use of
  974.             ClearCoat(tm).
  975.  
  976.           +o Graphics state information could "leak" from a
  977.             cliptexture to other models in the scene.  This has
  978.             been fixed (SCR 603185).
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.                                   - 16 -
  995.  
  996.  
  997.  
  998.        6.11.2  _N_e_w__F_e_a_t_u_r_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._4
  999.  
  1000.        6.11.2.1  _S_u_p_p_o_r_t__f_o_r__D_P_L_E_X__o_p_t_i_o_n
  1001.  
  1002.        Performer 2.2.4 includes support for the DPLEX option to
  1003.        Onyx2 Infinite Reality. This support has been affected
  1004.        without changes to the API, and modifications to the
  1005.        command-line options for perfly, clipfly, and asdfly have
  1006.        been made to enable DPLEX. There are, however, some changes
  1007.        to the semantics of _p_f_P_i_p_e, _p_f_P_i_p_e_W_i_n_d_o_w, and _p_f_C_h_a_n_n_e_l
  1008.        interaction.  This change is described below.
  1009.  
  1010.        Initialization of the hyperpipe is via the existing
  1011.        pfHyperpipe() API.  This call defines the number of _p_f_P_i_p_es
  1012.        to combine into a single hyperpipe.  Each call to
  1013.        pfHyperpipe() defines a separate hyperpipe instance. For
  1014.        example, two calls to pfHyperpipe() with an argument of 2
  1015.        would define two hyperpipes of 2 _p_f_P_i_p_es each to Performer.
  1016.        Like pfMultipipe(), this routine can only be invoked prior
  1017.        to pfConfig().  Additionally, the _p_f_P_i_p_es of the hyperpipes
  1018.        will be the lowest numbered _p_f_P_i_p_es, with any non-hyperpipe
  1019.        _p_f_P_i_p_es appearing at the end.
  1020.  
  1021.        The first (lowest numbered) _p_f_P_i_p_e of the hyperpipe is the
  1022.        master.  In the above example, that would be _p_f_P_i_p_es 0 and
  1023.        2.  All control of the hyperpipe should be made through the
  1024.        master _p_f_P_i_p_e. For example, to construct a _p_f_P_i_p_e_W_i_n_d_o_w for
  1025.        a hyperpipe, the application can simply create it on the
  1026.        master _p_f_P_i_p_e. The cloned _p_f_P_i_p_e_W_i_n_d_o_ws for each _p_f_P_i_p_e in
  1027.        the hyperpipe will be created automatically. While allowed,
  1028.        constructing a _p_f_P_i_p_e_W_i_n_d_o_w on a non-master pipe of the
  1029.        hyperpipe will lead to undefined results.
  1030.  
  1031.        Hyperpipes differ from other multipipe configurations in one
  1032.        other very important way. The set of _p_f_C_h_a_n_n_e_l_s displayed on
  1033.        the hyperpipe is shared amongst all of the _p_f_P_i_p_e_s in the
  1034.        hyperpipe.  That is, it is only necessary to create and set
  1035.        _p_f_C_h_a_n_n_e_l objects on the master _p_f_P_i_p_e of the hyperpipe.
  1036.        Since the hyperpipe is a time multiplexed view of these
  1037.        channels, Performer will propagate changes in the _p_f_C_h_a_n_n_e_l
  1038.        to each of the _p_f_P_i_p_e_s in turn.
  1039.  
  1040.        The following code snippet identifies the steps needed to
  1041.        setup a multi-hyperpipe config. It assumes that each of the
  1042.        hyperpipes are symetric (i.e., have the same number of
  1043.        pipes), although this is not required by Performer.
  1044.  
  1045.  
  1046.        ////****
  1047.         **** LLLLooooccccaaaallll ddddeeeeccccllllaaaarrrraaaattttiiiioooonnnnssss
  1048.         ****////
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.                                   - 17 -
  1061.  
  1062.  
  1063.  
  1064.        iiiinnnntttt iiii;;;;
  1065.        ppppffffCCCChhhhaaaannnnnnnneeeellll**** mmmmaaaasssstttteeeerrrrCCCChhhhaaaannnn;;;;
  1066.        ppppffffPPPPiiiippppeeeeWWWWiiiinnnnddddoooowwww**** mmmmaaaasssstttteeeerrrrPPPPWWWWiiiinnnn;;;;
  1067.  
  1068.        ////****
  1069.         **** TTTThhhheeee ffffoooolllllllloooowwwwiiiinnnngggg aaaassssssssuuuummmmeeeessss tttthhhhaaaatttt hhhhyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooouuuunnnntttt iiiissss tttthhhheeee nnnnuuuummmmbbbbeeeerrrr ooooffff
  1070.         **** hhhhyyyyppppeeeerrrrppppiiiippppeeeessss ttttoooo ccccoooonnnnffffiiiigggguuuurrrreeee aaaannnndddd hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt iiiissss tttthhhheeee nnnnuuuummmmbbbbeeeerrrr
  1071.         **** ppppiiiippppeeeessss ppppeeeerrrr hhhhyyyyppppeeeerrrrppppiiiippppeeee....
  1072.         ****////
  1073.        iiiinnnntttt ppppiiiippppeeeeCCCCoooouuuunnnntttt ==== hhhhyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooouuuunnnntttt****hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt;;;;
  1074.  
  1075.        ffffoooorrrr ((((iiii ==== 0000;;;; iiii <<<< hhhhyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooouuuunnnntttt;;;; iiii++++++++))))
  1076.            ppppffffHHHHyyyyppppeeeerrrrppppiiiippppeeee((((hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt))));;;;
  1077.  
  1078.        ////****
  1079.         **** CCCCoooonnnnffffiiiigggguuuurrrreeee PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr
  1080.         ****////
  1081.        ppppffffCCCCoooonnnnffffiiiigggg(((())));;;;
  1082.  
  1083.        ////****
  1084.         **** CCCCoooonnnnffffiiiigggguuuurrrreeee tttthhhheeee ssssccccrrrreeeeeeeennnnssss ffffoooorrrr tttthhhheeee ppppffffPPPPiiiippppeeeessss
  1085.         ****
  1086.         **** AAAAssssssssuuuummmmeeeessss aaaallllllll ssssaaaammmmeeee ddddiiiissssppppllllaaaayyyy aaaannnndddd ssssccccrrrreeeeeeeennnn aaaassssssssiiiiggggnnnnmmmmeeeennnnttttssss tttthhhhaaaatttt mmmmaaaapppp
  1087.         **** ttttoooo ppppffffPPPPiiiippppeeee nnnnuuuummmmbbbbeeeerrrr
  1088.         ****////
  1089.        ffffoooorrrr ((((iiii ==== 0000;;;; iiii <<<< ppppiiiippppeeeeCCCCoooouuuunnnntttt;;;; iiii++++++++))))
  1090.            ppppffffPPPPiiiippppeeeeSSSSccccrrrreeeeeeeennnn((((ppppffffGGGGeeeettttPPPPiiiippppeeee((((iiii)))),,,, iiii))));;;;  //////// aaaassssssssuuuummmmeeeessss aaaallllllll oooonnnn ssssaaaammmmeeee ddddiiiissssppppllllaaaayyyy
  1091.  
  1092.        ////****
  1093.         **** CCCCoooonnnnffffiiiigggguuuurrrreeee aaaa tttthhhhrrrreeeeeeee,,,, ttttwwwwoooo----ppppiiiippppeeee hhhhyyyyppppeeeerrrrppppiiiippppeeee ffffoooorrrr mmmmuuuullllttttiiii----cccchhhhaaaannnnnnnneeeellll ddddiiiissssppppllllaaaayyyy....
  1094.         ****////
  1095.        ffffoooorrrr ((((iiii ==== 0000;;;; iiii <<<< ppppiiiippppeeeeCCCCoooouuuunnnntttt;;;; iiii ++++==== hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt)))) {{{{
  1096.            ppppffffPPPPiiiippppeeee**** pppp;;;;
  1097.            ppppffffPPPPiiiippppeeeeWWWWiiiinnnnddddoooowwww**** ppppwwww;;;;
  1098.            ppppffffCCCChhhhaaaannnnnnnneeeellll**** cccchhhhaaaannnn;;;;
  1099.            iiiinnnntttt sssshhhhaaaarrrreeee;;;;
  1100.            PPPPFFFFVVVVEEEECCCC3333 xxxxyyyyzzzz,,,, hhhhpppprrrr;;;;
  1101.  
  1102.            pppp ==== ppppffffGGGGeeeettttPPPPiiiippppeeee((((iiii))));;;;
  1103.            ppppwwww ==== ppppffffNNNNeeeewwwwPPPPWWWWiiiinnnn((((pppp))));;;;
  1104.            ppppffffPPPPWWWWiiiinnnnNNNNaaaammmmeeee((((ppppwwww,,,, """"HHHHyyyyppppeeeerrrrppppiiiippppeeee WWWWiiiinnnnddddoooowwww""""))));;;;
  1105.            ppppffffPPPPWWWWiiiinnnnCCCCoooonnnnffffiiiiggggFFFFuuuunnnncccc((((ppppwwww,,,, OOOOppppeeeennnnPPPPiiiippppeeeeWWWWiiiinnnn))));;;;
  1106.            ppppffffPPPPWWWWiiiinnnnTTTTyyyyppppeeee((((ppppwwww,,,, PPPPFFFFPPPPWWWWIIIINNNN____TTTTYYYYPPPPEEEE____XXXX))));;;;
  1107.            ppppffffPPPPWWWWiiiinnnnFFFFuuuullllllllSSSSccccrrrreeeeeeeennnn((((ppppwwww))));;;;
  1108.            ppppffffPPPPWWWWiiiinnnnMMMMooooddddeeee((((ppppwwww,,,, PPPPFFFFWWWWIIIINNNN____NNNNOOOOBBBBOOOORRRRDDDDEEEERRRR,,,, 1111))));;;;
  1109.            ppppffffCCCCoooonnnnffffiiiiggggPPPPWWWWiiiinnnn((((ppppwwww))));;;;
  1110.            iiiiffff ((((iiii ======== 0000)))) mmmmaaaasssstttteeeerrrrPPPPWWWWiiiinnnn ==== ppppwwww;;;;
  1111.  
  1112.            cccchhhhaaaannnn ==== ppppffffNNNNeeeewwwwCCCChhhhaaaannnn((((pppp))));;;;
  1113.            sssshhhhaaaarrrreeee ==== ppppffffGGGGeeeettttCCCChhhhaaaannnnSSSShhhhaaaarrrreeee((((cccchhhhaaaannnn))));;;;
  1114.            sssshhhhaaaarrrreeee ||||==== PPPPFFFFCCCCHHHHAAAANNNN____VVVVIIIIEEEEWWWWPPPPOOOORRRRTTTT |||| PPPPFFFFCCCCHHHHAAAANNNN____SSSSWWWWAAAAPPPPBBBBUUUUFFFFFFFFEEEERRRRSSSS ||||
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122.  
  1123.  
  1124.  
  1125.  
  1126.                                   - 18 -
  1127.  
  1128.  
  1129.  
  1130.                     PPPPFFFFCCCCHHHHAAAANNNN____SSSSWWWWAAAAPPPPBBBBUUUUFFFFFFFFEEEERRRRSSSS____HHHHWWWW;;;;
  1131.            ppppffffCCCChhhhaaaannnnSSSShhhhaaaarrrreeee((((cccchhhhaaaannnn,,,, sssshhhhaaaarrrreeee))));;;;
  1132.            ppppffffMMMMaaaakkkkeeeeSSSSiiiimmmmpppplllleeeeCCCChhhhaaaannnn((((cccchhhhaaaannnn,,,, 44445555))));;;;
  1133.            ppppffffCCCChhhhaaaannnnAAAAuuuuttttooooAAAAssssppppeeeecccctttt((((cccchhhhaaaannnn,,,, PPPPFFFFFFFFRRRRUUUUSSSSTTTT____CCCCAAAALLLLCCCC____VVVVEEEERRRRTTTT))));;;;
  1134.            ppppffffAAAAddddddddCCCChhhhaaaannnn((((ppppwwww,,,, cccchhhhaaaannnn))));;;;
  1135.  
  1136.            ppppffffSSSSeeeettttVVVVeeeecccc3333((((xxxxyyyyzzzz,,,, 0000,,,, 0000,,,, 0000))));;;;
  1137.            ppppffffSSSSeeeettttVVVVeeeecccc3333((((hhhhpppprrrr,,,, ((((((((hhhhyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooouuuunnnntttt----1111)))) **** ....5555ffff
  1138.                         ---- iiii////hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt )))) **** 44445555....ffff,,,, 0000,,,, 0000))));;;;
  1139.            ppppffffCCCChhhhaaaannnnVVVViiiieeeewwwwOOOOffffffffsssseeeettttssss((((cccchhhhaaaannnn,,,, xxxxyyyyzzzz,,,, hhhhpppprrrr))));;;;
  1140.            iiiiffff ((((iiii ======== 0000))))
  1141.                mmmmaaaasssstttteeeerrrrCCCChhhhaaaannnn ==== cccchhhhaaaannnn;;;;
  1142.            eeeellllsssseeee
  1143.                ppppffffAAAAttttttttaaaacccchhhhCCCChhhhaaaannnn((((mmmmaaaasssstttteeeerrrrCCCChhhhaaaannnn,,,, cccchhhhaaaannnn))));;;;
  1144.        }}}}
  1145.  
  1146.        The remainder of the code should follow a typical multipipe
  1147.        application.
  1148.  
  1149.        There are certain restrictions on usage of _p_f_P_i_p_es,
  1150.        _p_f_P_i_p_e_W_i_n_d_o_ws and _p_f_P_i_p_e_V_i_d_e_o_C_h_a_n_n_e_ls when running in
  1151.        hyperpipe mode. All actions (with the exception of graphics
  1152.        pipe specific controls, e.g., pfPWinFBConfigAttrs() and
  1153.        pfPWinFBConfigId) should occur on those objects associated
  1154.        with the master _p_f_P_i_p_e.  In those instances where pipe
  1155.        specific attributes need modification, the appropriate
  1156.        pfPipeWindow or pfPipeVideoChannel can be obtained using the
  1157.        indexed pfGetPipePWin and pfGetPWinPVChan functions.  The
  1158.        index should equal the index of the associated master object
  1159.        on the master pipe.
  1160.  
  1161.        There is a limitation in that changes to _p_f_P_i_p_e_W_i_n_d_o_ws
  1162.        affected by the draw process will not be propagated to other
  1163.        _p_f_P_i_p_e_W_i_n_d_o_ws in the hyperpipe. Also, statistics drawn by
  1164.        the _p_f_F_r_a_m_e_S_t_a_t_s will reflect only the times for a
  1165.        particular draw process and not the entire hyperpipe. These
  1166.        problems may be removed in a later release.
  1167.  
  1168.  
  1169.        6.12  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._3
  1170.  
  1171.        6.12.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._3
  1172.  
  1173.           +o Performer 2.2 always used the channel frustum for
  1174.             culling when PFCULL_GSET was set, even if a custom cull
  1175.             frustum polytope was defined.  This has been fixed.
  1176.             (SCR 635693)
  1177.  
  1178.           +o Attempting to delete a cliptexture could cause a core
  1179.             dump.  Cliptexture deletion is not supported, so a
  1180.             DEBUG-level warning is now emitted.  (SCR 594276)
  1181.  
  1182.  
  1183.  
  1184.  
  1185.  
  1186.  
  1187.  
  1188.  
  1189.  
  1190.  
  1191.  
  1192.                                   - 19 -
  1193.  
  1194.  
  1195.  
  1196.           +o Fully transparent pfLPointStates could cause
  1197.             segmentation violations in Performer 2.2.  This has
  1198.             been fixed.  (SCR 614274)
  1199.  
  1200.           +o The FLT loader printed assertion failures such as the
  1201.             following:
  1202.  
  1203.                +o pfdConverterMode_flt: user data slot cannot be set
  1204.                  to 1
  1205.  
  1206.                +o pfdConverterMode_flt: private user data slot
  1207.                  cannot be set to 2
  1208.  
  1209.             The cause of these problems has been fixed.  (SCR
  1210.             624177)
  1211.  
  1212.           +o pfdFindConverterDSO was unable to locate the 3ds file
  1213.             loader. This was the result of conflicting IL and IFL
  1214.             versions and has been fixed.  (SCR 625838)
  1215.  
  1216.           +o The warning "pfTexture::compare(): pfClipTexture is not
  1217.             a pfTexture" was emitted when comparing a pfGeoState
  1218.             with cliptexture to one with a regular texture.  This
  1219.             has been fixed.  (SCR 626001)
  1220.  
  1221.           +o Picking with orthographic viewing frusta returned
  1222.             incorrect hit points.  This has been fixed.  (SCR
  1223.             601650)
  1224.  
  1225.           +o Color fields in pfGeoSets were not being handled
  1226.             correctly during the print traversal.  This has been
  1227.             fixed.  (SCR 621124)
  1228.  
  1229.           +o pfuTravCalcBBox in trav.c did not calculate the
  1230.             bounding box for pfBillboard nodes.  It now does.  (SCR
  1231.             632225)
  1232.  
  1233.  
  1234.  
  1235.        6.13  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._2
  1236.  
  1237.        6.13.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._2
  1238.  
  1239.           +o _p_f_B_i_l_l_b_o_a_r_d_s were always using Z axis (Bug #591154)
  1240.  
  1241.           +o _p_f_P_i_p_e_W_i_n_d_o_w _r_e_s_i_z_e _w_i_t_h _f_o_r_k_e_d _c_u_l_l caused per-frame
  1242.             slow X communication. (Bug #611816)
  1243.  
  1244.           +o _p_f_T_e_x_t_u_r_e _w_i_t_h _T_e_x_L_O_D _s_e_t_t_i_n_g_s would leak memory. (Bug
  1245.             #600949)
  1246.  
  1247.  
  1248.  
  1249.  
  1250.  
  1251.  
  1252.  
  1253.  
  1254.  
  1255.  
  1256.  
  1257.  
  1258.                                   - 20 -
  1259.  
  1260.  
  1261.  
  1262.           +o _p_f_U_n_r_e_f_D_e_l_e_t_e() would delete an object when its ref
  1263.             count was decremented to 65536.  This has been fixed,
  1264.             and the types of pfGetRef() and pfUnrefGetRef() have
  1265.             been changed from ushort to int. (Bug #603177)
  1266.  
  1267.           +o The _l_o_o_k_a_h_e_a_d directive was ignored in no-imagecache
  1268.             ._c_t _c_l_i_p _t_e_x_t_u_r_e _c_o_n_f_i_g_u_r_a_t_i_o_n _f_i_l_e_s.  _N_O_T_E: since this
  1269.             is fixed, applications using .ct files containing a
  1270.             lookahead command may use much more memory, and may
  1271.             have to be re-tuned (or the lookahead command removed).
  1272.             (Bug #576096)
  1273.  
  1274.           +o The CSB loader has been updated to enable loading of
  1275.             files created by OpenGL Optimizer 1.2
  1276.  
  1277.           +o The FLT loader has been updated to version 15.4g (Bug
  1278.             #615990).  Several bugs have been fixed, including:
  1279.  
  1280.                +o A bug in revision R15.4fi where
  1281.                  pfuTexGenClipCenterNode was inserted as parent of
  1282.                  root node.  In such cases the clip texture was not
  1283.                  centered.
  1284.  
  1285.                +o A bug in revision R15.4fi where the loader's user
  1286.                  data slot was not initialized.  This caused core
  1287.                  dumps when certain run-time features were enabled
  1288.                  such as clip planes, behaviors, and adaptive light
  1289.                  points.
  1290.  
  1291.                +o _P_r_o_j_e_c_t_e_d _t_e_x_t_u_r_e_s behaved improperly when using
  1292.                  multiple channels or when lighting was off. (Bugs
  1293.                  #581332, #581334)
  1294.  
  1295.                +o _I_n_f _f_r_a_m_e _r_a_t_e _r_e_p_o_r_t_e_d _f_o_r _I_n_t_e_r_l_a_c_e_d _v_i_d_e_o
  1296.                  _f_o_r_m_a_t_s.  Now, the current swap rate will be
  1297.                  reported which for interlaced video formats might
  1298.                  be faster than the requested frame rate (ie.
  1299.                  60/30Hz).  (Bug #603567).
  1300.  
  1301.                +o _v_i_s_f_l_y _d_e_m_o was unable to start due to an
  1302.                  unresolvable symbol in the compat libraries,
  1303.                  pfuCalcNormalizedChanXY (Bug #600942)
  1304.  
  1305.                +o _B_a_d _L_i_g_h_t_i_n_g - the 2.0.6/2.1.4 compat libraries
  1306.                  had bad lighting characteristics; all lit models
  1307.                  were shaded grey  (Bug #598903)
  1308.  
  1309.                +o _p_f_d_F_i_n_d_C_o_n_v_e_r_t_e_r_D_S_O() in 2.0.6/2.1.4 was failing
  1310.                  due to a lookup problem in pfdLoadFile.  (Bug
  1311.                  #605958)
  1312.  
  1313.  
  1314.  
  1315.  
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321.  
  1322.  
  1323.  
  1324.                                   - 21 -
  1325.  
  1326.  
  1327.  
  1328.                +o _6_4_b_i_t _o_p_e_r_a_t_i_o_n _w_i_t_h _I_R_I_X _6._5 could fail with IRIS
  1329.                  Performer 2.0 and 2.1 libraries.  This is fixed in
  1330.                  the IRIS Performer libraries that were shipped
  1331.                  with IRIX 6.5 and also in the 2.0.7/2.1.5
  1332.                  libraries.
  1333.  
  1334.  
  1335.        6.14  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._1
  1336.  
  1337.        6.14.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._1
  1338.  
  1339.           +o _a_s_d_f_l_y _z_b_u_f_f_e_r _p_r_o_b_l_e_m_s _o_n _i_R due to a lose layer
  1340.             offset call in asdfly/terrain.c. (Bug #575993)
  1341.  
  1342.           +o _M_u_l_t_i_p_i_p_e _C_a_l_l_i_g_r_a_p_h_i_c_s supports 10 pipes instead of
  1343.             just 3.  (Bug #559773)
  1344.  
  1345.           +o _M_u_l_t_i_p_i_p_e _p_f_G_e_t_S_c_r_e_e_n() _r_e_t_u_r_n_i_n_g (-_1)_i_n _d_r_a_w _s_t_a_g_e
  1346.             _c_a_l_l_b_a_c_k _i_n_i_t..
  1347.  
  1348.           +o _O_p_e_n_W_o_r_l_d_s _V_R_M_L _2._0 (._w_r_l) _l_o_a_d_e_r failed for N32 and
  1349.             N64 due to default library search path
  1350.             (/usr/lib[32,64]. (Bug #575792)
  1351.  
  1352.           +o _O_p_e_n_F_l_i_g_h_t (._f_l_t) _l_o_a_d_e_r _w_i_t_h _a_u_t_o_m_a_t_i_c _c_l_i_p_t_e_x_t_u_r_e
  1353.             _c_e_n_t_e_r_i_n_g could dump core if pfuInit() was not called
  1354.             by the application before pfConfig().  (Bug #575589)
  1355.  
  1356.           +o _O_p_e_n_F_l_i_g_h_t (._f_l_t) _l_o_a_d_e_r _u_s_i_n_g _n_e_w _1_5._4 _f_e_a_t_u_r_e_s could
  1357.             dump core due to lack of initialization of user data
  1358.             slot used for behaviors and clip planes.  (Bug #575586)
  1359.  
  1360.           +o _X_s_g_i_v_c _V_i_d_e_o _C_h_a_n_n_e_l _0 had to exist or Performer would
  1361.             hang on startup.  This also caused hangs on OCTANE OCO
  1362.             (multi-channel operation).  (Bug #577815)
  1363.  
  1364.           +o _N_6_4 _V_i_d_e_o _c_h_a_n_n_e_l _o_p_e_r_a_t_i_o_n_s would dump core (Bug
  1365.             #575616).  To see this fix on IRIX 6.2 or IRIX 6.4,
  1366.             additional X and GL patches are required.
  1367.  
  1368.           +o _I_n _O_c_t_a_n_e _O_C_O _m_o_d_e  _o_r _n_o _v_i_d_e_o _c_h_a_n_n_e_l  would result
  1369.             in no pfPipeWindow being opened. (Bug #577065).
  1370.  
  1371.           +o _D_V_R _s_h_o_w_i_n_g _n_o_i_s_e _o_n _b_o_t_t_o_m _l_i_n_e_s _o_f _v_i_d_e_o. (Bug
  1372.             #577976).
  1373.  
  1374.           +o _p_f_i_S_p_h_e_r_i_c _m_o_t_i_o_n _m_o_d_e_l _t_r_a_n_s_i_t_i_o_n (rail) tracking was
  1375.             too fast for really slow speeds (in the range of
  1376.             0.000001).  (Bug #583127).
  1377.  
  1378.  
  1379.  
  1380.  
  1381.  
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.                                   - 22 -
  1391.  
  1392.  
  1393.  
  1394.        6.14.2  _P_r_o_b_l_e_m_s _f_i_x_e_d _i_n _2._0._6 _a_n_d _2._1._4 (_s_h_i_p_p_e_d _w_i_t_h
  1395.        _2._2._1)
  1396.  
  1397.           +o _p_f_u_C_o_n_f_i_g_M_C_O now properly initializes multiple channels
  1398.             on multiple pipes. (Bug #564062)
  1399.  
  1400.           +o _p_f_W_i_n_d_o_w::_g_e_t_F_B_C_o_n_f_i_g_A_t_t_r_s() was core dumping on
  1401.             pbuffers.  It will now return NULL for a pbuffer since
  1402.             the attribute arrays is for XVisuals and pbuffers
  1403.             require GLXFBConfigSGIXs which should be specified with
  1404.             pfWindow::setFBConfig(). (Bug #575989)
  1405.  
  1406.           +o _p_f_u_S_a_v_e_I_m_a_g_e _i_n _N_6_4 didn't work due to bad pointer
  1407.             types in libpfutil/snapwin.c. (Bug #575243)
  1408.  
  1409.           +o _N_6_4 _p_l_a_c_e_m_e_n_t _o_f _p_f_D_a_t_a_P_o_o_l_s could cause brk to run out
  1410.             of space for heap area. (Bug #575065)
  1411.  
  1412.  
  1413.        6.15  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2
  1414.  
  1415.        6.15.1  _I_R_I_S__P_e_r_f_o_r_m_e_r__2_._0_._4__P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__2_._0_._5__a_n_d__2_._2
  1416.  
  1417.  
  1418.           +o _p_f_I_n_i_t_C_l_o_c_k in 250MHz IMPACT use not to be consistent.
  1419.  
  1420.           +o _P_i_c_k_i_n_g models with LOD unded DCS used to fail with
  1421.             large DCS translations (bug#455490)
  1422.  
  1423.           +o _p_f_T_e_x_t_u_r_e sometime failed to restore to the global
  1424.             texture.
  1425.  
  1426.           +o _p_f_B_o_x contains function has been fixed
  1427.  
  1428.           +o _D_a_t_a_P_o_o_l were not aligned on 64 bits, generating core
  1429.             dump if the application store double float in the
  1430.             datapool.
  1431.  
  1432.           +o Some _q_u_e_r_y feature request were missing, 2.0.5 is now
  1433.             at the same level as 2.2.
  1434.  
  1435.           +o Assigning a Drawable without a visual used to cause the
  1436.             window not to open. (bug# 450891)
  1437.  
  1438.           +o Full screen had a window border when compiling for N64.
  1439.             (bug #542372)
  1440.  
  1441.           +o _p_b_u_f_f_e_r were not fully supported.
  1442.  
  1443.  
  1444.  
  1445.  
  1446.  
  1447.  
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.                                   - 23 -
  1457.  
  1458.  
  1459.  
  1460.        6.15.2  _I_R_I_S__P_e_r_f_o_r_m_e_r__2_._1_._2__P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__2_._1_._3__a_n_d__2_._2
  1461.  
  1462.  
  1463.           +o When the first video channel on a graphic pipeline was
  1464.             not active, _p_f_P_i_p_e_V_i_d_e_o_C_h_a_n_n_e_l was failing under forked
  1465.             DRAW multi-process.
  1466.  
  1467.           +o _A_S_D _T_e_r_r_a_i_n was not supporting dynamic paging. This
  1468.             fixed so ASD tiles can be dynamically paged in the
  1469.             DBASE prmcess.
  1470.  
  1471.           +o _A_S_D _T_e_r_r_a_i_n was not working on multipipe. This is fixed
  1472.             and ASD works fine with multiple pipes/channels. _a_s_d_f_l_y
  1473.             is fixed as well.
  1474.  
  1475.           +o _V_e_r_t_e_x _a_r_r_a_y_s used in a GL display list used to produce
  1476.             invalid normals.  This has been fixed in OpenGL with
  1477.             patch 1808 or later.
  1478.  
  1479.           +o _p_f_T_e_x_t_u_r_e sometime failed to restore to the global
  1480.             texture.
  1481.  
  1482.           +o _p_f_B_o_x contains function has been fixed
  1483.  
  1484.           +o _D_a_t_a_P_o_o_l were not aligned on 64 bits, generating core
  1485.             dump if the application store double float in the
  1486.             datapool.
  1487.  
  1488.           +o Full screen had a window border when compiling for N64.
  1489.             (bug #542372)
  1490.  
  1491.           +o Some _q_u_e_r_y feature request were missing, 2.1.3 is now
  1492.             at the same level as 2.2.
  1493.  
  1494.           +o _M_o_t_i_f decoration hints used not to work in 64 bits N64.
  1495.  
  1496.  
  1497.        6.15.3  _O_t_h_e_r__P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__2_._2
  1498.  
  1499.           +o _I_n_v_e_n_t_o_r loader used not to work N32/N64. (bug# 434322)
  1500.  
  1501.           +o _G_a_n_g_S_w_a_p was not working at all for OpenGL. This is
  1502.             fixed in performer and in OpenGL after patch 1808.
  1503.  
  1504.           +o _p_e_r_f_l_y did not accept input from other screens than the
  1505.             master screen. (bug# 459186)
  1506.  
  1507.           +o _E_a_r_t_h_S_k_y used not to propagate the right fog values in
  1508.             sync to all screens in multipipe mode (bug# 437747)
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514.  
  1515.  
  1516.  
  1517.  
  1518.  
  1519.  
  1520.  
  1521.  
  1522.                                   - 24 -
  1523.  
  1524.  
  1525.  
  1526.           +o _s_h_a_d_o_w _t_e_x_t_u_r_e_s used not to be implemented for
  1527.             InfiniteReality/OpenGL.
  1528.  
  1529.           +o _p_f_c_o_n_v did core dump or go in infinite loop when
  1530.             converting some inventor files. (bug# 435232)
  1531.  
  1532.           +o _g_l_o_b_a_l _s_t_a_t_e used not to work properly and be in
  1533.             conflict with channel state (see option -q0 in perfly).
  1534.             (bug# 423829)
  1535.  
  1536.           +o _B_i_n_s used to have many problems. Bin number had to be
  1537.             in successive numbers (bug# 416557), bin Order had no
  1538.             effect at all, there was no way to draw the objects
  1539.             that are not falling into a bin (can be done in 2.2
  1540.             using pfDrawBin(-1)), there was no way to know which
  1541.             bins are in used (pfGetFreeBin() gets that information
  1542.             in 2.2). Note that 2.2 has a predefined #3 bin: the
  1543.             Light Point bin, and that this bin has a very special
  1544.             behavior and cannot be used for general purpose.
  1545.  
  1546.           +o _p_f_A_S_D used to only handle terrain with less than 65000
  1547.             vertices.
  1548.  
  1549.           +o _p_f_d_B_u_i_l_d_A_S_D used to have memory corruptions.
  1550.  
  1551.           +o _D_V_R used to produce garbage when used on a screen
  1552.             larger than 1280 pixels. Performer now prevent scaling
  1553.             in X direction as the hardware does not support it. It
  1554.             is not going to be fixed in OpenGL, it is a HW
  1555.             bandwidth limitation.
  1556.  
  1557.           +o _g_l_N_o_r_m_a_l_i_z_e was turned on by default, resulting in a
  1558.             minimal loss of performances. Now it is automatically
  1559.             turned on only when the current transformation matrix
  1560.             includes scaling, and turned off otherwise.
  1561.  
  1562.           +o Some _p_f_M_a_t_h routines were slower than system libmath
  1563.             routines that are now very optimized. The corresponding
  1564.             pfMath routines are replaced by a #define that calls
  1565.             system math routines directly.
  1566.  
  1567.           +o _C_l_i_p_t_e_x_t_u_r_e have been upgraded to production standards
  1568.             for IRIS Performer 2.2. The core cliptexture
  1569.             functionality has been respecified to tighter
  1570.             tolerances, critical functionality such as load control
  1571.             and virtual cliptextures has been added, and additional
  1572.             API in libpfutil and libpfdu has been put in to make
  1573.             cliptextures easier to use in production applications.
  1574.  
  1575.           +o _p_e_r_f_l_y -_t now allows specification of visual ID for
  1576.             each pipe as a comma-separated list.
  1577.  
  1578.  
  1579.  
  1580.  
  1581.  
  1582.  
  1583.  
  1584.  
  1585.  
  1586.  
  1587.  
  1588.                                   - 25 -
  1589.  
  1590.  
  1591.  
  1592.           +o _p_f_F_o_n_t._h in previous versions was missing some internal
  1593.             fields in the class declaration that would cause
  1594.             problems for C++ user code creating pfFont structures
  1595.             and the allocates structures would not be the proper
  1596.             size.
  1597.  
  1598.  
  1599.  
  1600.        6.15.4  _D_i_f_f_e_r_e_n_c_e_s__B_e_t_w_e_e_n__2_._2__a_n_d__2_._0_/_2_._1
  1601.        IRIS Performer 2.1 is an enhanced version of the IRIS
  1602.        Performer 2.0 release designed in conjunction with the Onyx
  1603.        InfiniteReality graphics hardware. It is, in essence,
  1604.        "Performer 2.0 with InfiniteReality extensions." Unlike IRIS
  1605.        Performer 2.1 that was only for InfiniteReality, the new
  1606.        IRIS Performer 2.2 is an enhanced version of IRIS Performer
  1607.        2.0/2.1 that runs on all SGI plateformes, enabling hardware
  1608.        specific features (DVR, ClipMapping) only when supported
  1609.        directly by the Graphic Subsystem.  IRIS Performer 2.2 has
  1610.        numerous improvements and new features over 2.0/2.1 such as
  1611.        pfFlux, pfb/pfi file formats, compute process for ASD,
  1612.        Calligraphic light support....  IRIS Performer 2.0 API is
  1613.        almost unchanged into 2.2, but it is not the case for 2.1 as
  1614.        the ClipMapping and ASD have had a lot of API changes.
  1615.  
  1616.  
  1617.        6.15.4.1  _C_l_i_p_T_e_x_t_u_r_e
  1618.  
  1619.        InfiniteReality supports very large textures through a
  1620.        virtual mipmapped texture scheme we call cliptexturing. Here
  1621.        is a preview of the basic concepts.
  1622.  
  1623.        Clip Textures provide a way use texture maps too large to
  1624.        hold in graphics texture memory. Until now, to use a large
  1625.        texture, you had to break it into tiles, bringing in the
  1626.        next texture as you approached a tile boundary.  This
  1627.        approach has numerous problems, including what to do about
  1628.        polygons that span texture tile boundaries, properly
  1629.        handling the changes in texture coordinates, doing
  1630.        MIPMapping without visual artifacts, etc.  Performer Clip
  1631.        Textures solve these problems. They allow you to seamlessly
  1632.        use a very large texture, letting performer handle the
  1633.        loading issues.  Since it is one continuous texture, there
  1634.        are no problems with texture seams or changes in texture
  1635.        coordinates.
  1636.  
  1637.        A clip texture can be thought of as a very large mipmapped
  1638.        texture. The dimensions of level 0, the highest resolution
  1639.        level of the texture, is the clip texture's *virtual size*.
  1640.        For any given scene, only a subset of the entire clip
  1641.        texture is visible to the observer. pfClipTextures augment
  1642.        pfTextures by adding the notion of a center, a location in
  1643.  
  1644.  
  1645.  
  1646.  
  1647.  
  1648.  
  1649.  
  1650.  
  1651.  
  1652.  
  1653.  
  1654.                                   - 26 -
  1655.  
  1656.  
  1657.  
  1658.        texel space that is close to the observer. As the center
  1659.        moves, the cliptexture must repeatedly applied, to update
  1660.        the texels in texture memory, so that contains the texels
  1661.        surrounding the current center.
  1662.  
  1663.        With the center properly updated, only a subset of the
  1664.        entire cliptexture need be loaded into texture memory at any
  1665.        given time. The visible region of this texture is called the
  1666.        *clip region*. The contents of this region are updated as
  1667.        the cliptexture center changes, always keeping the
  1668.        surrounding texel data available to the texturing hardware.
  1669.        The clip region can be visualized as a fixed width square
  1670.        column cutting through the mipmap levels. At the coarsest
  1671.        levels, where the MIPmap level becomes smaller than the clip
  1672.        region size, the cliptexture is a normal MIPmap pyramid. As
  1673.        the center moves on level 0, the column shears so that it
  1674.        surrounds the center, each level moving half as fast as the
  1675.        finer level above it.
  1676.  
  1677.        The texture itself is stored on disk and system memory as
  1678.        *tiles*. One or more tiles are stored as *texture tile
  1679.        files* on disk, and are brought into system memory as
  1680.        needed. A cache of these tiles, called the *memory region*
  1681.        is kept in system memory to reduce disk latency. A subset of
  1682.        the memory region texels, the *texture region* are
  1683.        downloaded to the graphics hardware texture memory.
  1684.  
  1685.        Each level of the clip texture larger than the clip size is
  1686.        contained in an level updated with the proper texel data,
  1687.        based on the center position at that level. The image cache
  1688.        must download texel data as tiles from the appropriate
  1689.        texture data files, keeping the mem region updated, and use
  1690.        texture subloads to update texel data from the texture
  1691.        region into proper area of hardware texture memory.  The
  1692.        clip texture itself is composed of image caches and image
  1693.        tiles. The image tiles describe the levels of the mipmap
  1694.        pyramid that are equal to or smaller than the clip region.
  1695.        It updates the clip texture center, and commands the image
  1696.        caches to reapply the texture memory as the center changes.
  1697.  
  1698.        The application can configure a clip texture by loading
  1699.        _c_o_n_f_i_g_u_r_a_t_i_o_n _f_i_l_e_s, contains information about the texel
  1700.        data, cliptexture sizes, and texture file names and
  1701.        locations. A configured cliptexture can be used in the scene
  1702.        graph like a normal pfTexture. The application can attach
  1703.        mpcliptextures to cliptextures, and pipes to mpcliptextures
  1704.        automates the cliptexture apply process each frame, and
  1705.        allows cliptexture updates to be done in the application
  1706.        process. Every frame, the application updates the
  1707.        mpcliptexture _c_l_i_p_m_a_p _c_e_n_t_e_r. This can be automated by
  1708.        adding _c_e_n_t_e_r _n_o_d_e_s nodes to the scenegraph.
  1709.  
  1710.  
  1711.  
  1712.  
  1713.  
  1714.  
  1715.  
  1716.  
  1717.  
  1718.  
  1719.  
  1720.                                   - 27 -
  1721.  
  1722.  
  1723.  
  1724.        Cliptextures have a load control feature called Dynamic
  1725.        Texture Resolution (DTR). This feature allows clipmaps to be
  1726.        roamed faster than the system bandwidth would normally
  1727.        allow. DTR accomplishes this by improving the order in which
  1728.        tiles are download into image caches, and selectively
  1729.        blurring the cliptexture and adjusting the effective
  1730.        clipsize in order to modulate the cliptextures bandwidth
  1731.        requirements. DTR is controlled through a mode bitmask,
  1732.        which is used to enable or disable various load control
  1733.        features, and by a set of parameters that can be adjusted by
  1734.        the application to tune load control performance.
  1735.  
  1736.        There is a special form of clipmaps, called virtual
  1737.        clipmaps, which can be used to exceed some of the
  1738.        limitations in maximum virtual size and number of levels
  1739.        inherent in the system hardware. Virtual clipmaps trade off
  1740.        larger possible cliptextures against increased complexity,
  1741.        and additional interactions between the cliptexture and the
  1742.        scenegraph. With virtual cliptextues, the cliptexture,
  1743.        itself a virtualization of a MIPmap, is itself virtualized.
  1744.        The physical cliptexture is roamed within a larger virtual
  1745.        cliptexture in three dimensions; s, t, and level of detail
  1746.        (LOD). This roaming is controlled by setting the center and
  1747.        adjusting the virtualLOD offset. The number of physical
  1748.        clipmap levels in use is controlled by adjusting the
  1749.        effective levels parameter. When many levels need to be
  1750.        accessed, the virtuallodoffset and other parameters can be
  1751.        dynamically modified as the scenegraph is traversed, trading
  1752.        off some performance for much wider range of available LOD
  1753.        levels.
  1754.  
  1755.        Man pages to see: pfClipTexture, pfQueue, pfImageTile
  1756.  
  1757.        Demos to check out:
  1758.  
  1759.                /usr/share/Performer/data/clipdata/hunter/run_hl
  1760.                /usr/share/Performer/data/clipdata/moffett/run_mof
  1761.  
  1762.        Sample programs to check out:
  1763.  
  1764.                /usr/share/Performer/src/pguide/libpr/icache.c
  1765.                /usr/share/Performer/src/pguide/libpr/icache_mwin.c
  1766.                /usr/share/Performer/src/pguide/libpf/cliptex.c
  1767.                /usr/share/Performer/src/sample/C/perfly
  1768.  
  1769.        Utilities to use:
  1770.  
  1771.                /usr/share/Performer/src/libpfutil/cliptexture.c
  1772.                /usr/share/Performer/src/libpfutil/clipcenter.c
  1773.  
  1774.  
  1775.  
  1776.  
  1777.  
  1778.  
  1779.  
  1780.  
  1781.  
  1782.  
  1783.  
  1784.  
  1785.  
  1786.                                   - 28 -
  1787.  
  1788.  
  1789.  
  1790.        ClipTexture Texture Data and Configuration Files:
  1791.  
  1792.                /usr/share/Performer/data/clipdata/hunter
  1793.                /usr/share/Performer/data/clipdata/moffett
  1794.                *.ic - image cache configuration files
  1795.                *.ct - cliptexture configuration files
  1796.  
  1797.  
  1798.  
  1799.        6.15.4.2  _V_i_r_t_u_a_l__c_l_i_p_t_e_x_t_u_r_e_s
  1800.  
  1801.        Virtual cliptextures of up to 1<<23 (8 million) texels on a
  1802.        side are supported by IRIS Performer 2.2.  This allows a
  1803.        real cliptextures (currently limited in size by the
  1804.        InfiniteReality hardware to at most 32Kx32K texels) to be
  1805.        embedded in a larger virtual clipmap of up to 8Mx8M texels.
  1806.  
  1807.        The application controls the position of the real
  1808.        cliptexture within the virtual cliptexture by updating the
  1809.        center and the _v_i_r_t_u_a_l _L_O_D _o_f_f_s_e_t. The offset adjusts the
  1810.        real cliptexture in the LOD direction.  The real cliptexture
  1811.        can only occupy positions that are valid subsets of the
  1812.        virtual cliptexture. The number of valid locations can be
  1813.        increased by using less _e_f_f_e_c_t_i_v_e _l_e_v_e_l_s The real
  1814.        cliptexture will automatically be centered around the
  1815.        current center of the virtual cliptexture, which the
  1816.        application sets on a per-frame basis (see above).
  1817.  
  1818.        Utilities are provided for intelligently selecting where to
  1819.        offset the real clipmap within the virtual clipmap each
  1820.        frame.  For details, see the source code for
  1821.        pfuCalcSizeFinestMipLOD in libpfutil, and play with the
  1822.        "Clip LOD Offset" slider in perfly when viewing a clip
  1823.        texture bigger than 32Kx32K.
  1824.  
  1825.  
  1826.        6.15.4.3  _A_c_t_i_v_e__S_u_r_f_a_c_e__D_e_f_i_n_i_t_i_o_n
  1827.  
  1828.        A pfASD is a pfNode which can handle very large terrain
  1829.        surfaces that are described as multiple LODs.  Active
  1830.        Surface Definition accuratedly describes different portions
  1831.        of the terrain using triangles from different LODs.  The
  1832.        multiple LODs have a coherent subdivision-surfaces-like
  1833.        relationship between the neighboring levels.  pfASD contains
  1834.        a small scene graph that is generated dynamically to reflect
  1835.        the current visible geometry being rendered.
  1836.  
  1837.        These routines implement the Active Surface Definition (ASD)
  1838.        feature.  ASD defines a hierarchical structure that
  1839.        organizes all the LODs of a terrain. At run-time, ASD
  1840.        traverses the structure, selecting triangles from different
  1841.  
  1842.  
  1843.  
  1844.  
  1845.  
  1846.  
  1847.  
  1848.  
  1849.  
  1850.  
  1851.  
  1852.                                   - 29 -
  1853.  
  1854.  
  1855.  
  1856.        LODs to render the portion of the terrain that is within a
  1857.        volume of interest. Triangles are rendered either at their
  1858.        pre-stored locations, when they are in a particular LOD
  1859.        range, or at computed morphed locations, when they are
  1860.        within the morphing zone of a LOD range. There will be other
  1861.        ways to evaluate the terrain other than purely range based
  1862.        approach. The way to evaluate each vertex is the "evaluation
  1863.        function".  The evaluation function can be defined as a user
  1864.        call back function, when the default range based evaluation
  1865.        is not appropriate.
  1866.  
  1867.        An example of a user defined callback function can be found
  1868.        in
  1869.  
  1870.                /usr/share/Performer/src/sample/C/asdfly/eval_function.c
  1871.  
  1872.  
  1873.        pfASD has its own thread when user claimed multiprocessing
  1874.        mode, e.g.  PFMP_FORK_COMPUTE. Asychronizely, the evaluation
  1875.        of the structure is done in the thread and the created
  1876.        geometry (active mesh) are merged into the scenegraph
  1877.        internal to pfASD at pfFrame time.  pfASD enlarges the
  1878.        viewing frustum to accommodate the delay of evaluation.
  1879.  
  1880.        The cull of pfASD is handled together with the evaluation.
  1881.        In another word, the gsets that are generated by evaluation
  1882.        is the set of triangles that should be or soon to be
  1883.        visible.
  1884.  
  1885.        pfASD handles multichannel evaluation and ensures that
  1886.        neighboring channels will have consistently connected
  1887.        triangles.  A channel can also share the evaluated active
  1888.        mesh from another channel using pfChannel::ASDattach.  pfASD
  1889.        handles multipipe as well.
  1890.  
  1891.  
  1892.        6.15.4.4  _F_l_u_x__a_n_d__E_n_g_i_n_e
  1893.  
  1894.        A _p_f_F_l_u_x is a container for holding dynamic data.  It
  1895.        contains multiple buffers of data each associated with a
  1896.        frame number.  This allows multiple processes to each have a
  1897.        copy of the data appropriate to the frame they are working
  1898.        on. A full pfGeoSet can be fluxed pfFlux should be used
  1899.        instead of pfCycleBuffer as they do not require a copy of
  1900.        the data to be done to synchronize the stages of the process
  1901.        pipeline.
  1902.  
  1903.        A _p_f_E_n_g_i_n_e is an object that controls the dynamic data in a
  1904.        pfFlux.  A pfEngine of type PFENG_MORPH associated with a
  1905.        pfFlux replaces a pfMorph node.
  1906.  
  1907.  
  1908.  
  1909.  
  1910.  
  1911.  
  1912.  
  1913.  
  1914.  
  1915.  
  1916.  
  1917.  
  1918.                                   - 30 -
  1919.  
  1920.  
  1921.  
  1922.        see _p_f_F_l_u_x, _p_f_E_n_g_i_n_e, _p_f_F_S_C, _p_f_S_w_i_t_c_h and _p_f_L_O_D man pages.
  1923.  
  1924.  
  1925.        6.15.5  _D_i_f_f_e_r_e_n_c_e_s__B_e_t_w_e_e_n__2_._2__a_n_d__2_._1
  1926.  
  1927.  
  1928.        6.15.5.1  _C_l_i_p_M_a_p_p_i_n_g
  1929.  
  1930.        _p_f_I_m_a_g_e_C_a_c_h_e renamed some API calls (the corresponding gets
  1931.        are  not shown)
  1932.  
  1933.  
  1934.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeOOOOrrrriiiiggggiiiinnnn
  1935.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeMMMMeeeemmmmRRRReeeeggggiiiioooonnnnOOOOrrrrgggg
  1936.  
  1937.  
  1938.  
  1939.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeSSSSiiiizzzzeeee
  1940.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeMMMMeeeemmmmRRRReeeeggggiiiioooonnnnSSSSiiiizzzzeeee
  1941.  
  1942.  
  1943.  
  1944.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVVaaaalllliiiiddddRRRReeeeggggiiiioooonnnnOOOOrrrriiiiggggiiiinnnn
  1945.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeTTTTeeeexxxxRRRReeeeggggiiiioooonnnnOOOOrrrrgggg
  1946.  
  1947.  
  1948.  
  1949.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVVaaaalllliiiiddddRRRReeeeggggiiiioooonnnnSSSSiiiizzzzeeee
  1950.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeTTTTeeeexxxxRRRReeeeggggiiiioooonnnnSSSSiiiizzzzeeee
  1951.  
  1952.  
  1953.  
  1954.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVVaaaalllliiiiddddRRRReeeeggggiiiioooonnnnDDDDsssstttt
  1955.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeTTTTeeeexxxx
  1956.  
  1957.  
  1958.  
  1959.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVVaaaalllliiiiddddRRRReeeeggggiiiioooonnnnDDDDssssttttSSSSiiiizzzzeeee
  1960.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeTTTTeeeexxxxSSSSiiiizzzzeeee
  1961.  
  1962.  
  1963.  
  1964.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVViiiirrrrttttuuuuaaaallllSSSSiiiizzzzeeee
  1965.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeIIIImmmmaaaaggggeeeeSSSSiiiizzzzeeee
  1966.  
  1967.  
  1968.  
  1969.                oooobbbbssssoooolllleeeetttteeee:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeCCCCeeeennnntttteeeerrrr
  1970.                oooobbbbssssoooolllleeeetttteeee:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeMMMMaaaaxxxxUUUUppppddddaaaatttteeeeSSSSiiiizzzzeeee
  1971.  
  1972.  
  1973.  
  1974.  
  1975.  
  1976.  
  1977.  
  1978.  
  1979.  
  1980.  
  1981.  
  1982.  
  1983.  
  1984.                                   - 31 -
  1985.  
  1986.  
  1987.  
  1988.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeCCCCaaaallllccccTTTTeeeexxxxRRRReeeeggggiiiioooonnnn
  1989.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeCCCCaaaallllccccMMMMeeeemmmmRRRReeeeggggiiiioooonnnn
  1990.  
  1991.  
  1992.        _p_f_Q_u_e_u_e as new functionality
  1993.  
  1994.  
  1995.                nnnneeeewwww:::: ppppffffQQQQuuuueeeeuuuueeeeSSSSoooorrrrttttMMMMooooddddeeee
  1996.                nnnneeeewwww:::: ppppffffQQQQuuuueeeeuuuueeeeSSSSoooorrrrttttFFFFuuuunnnncccc
  1997.                nnnneeeewwww:::: ppppffffQQQQuuuueeeeuuuueeeeIIIInnnnppppuuuuttttRRRRaaaannnnggggeeee
  1998.                nnnneeeewwww:::: ppppffffQQQQuuuueeeeuuuueeeeOOOOuuuuttttppppuuuuttttRRRRaaaannnnggggeeee
  1999.                nnnneeeewwww:::: ppppffffGGGGeeeettttQQQQuuuueeeeuuuueeeeSSSSoooorrrrttttPPPPrrrrooooccccPPPPIIIIDDDD
  2000.  
  2001.  
  2002.        _p_f_I_m_a_g_e_C_a_c_h_e now use sorting queus Image cache configuration
  2003.        files have a version2.0 format. The parser will run with
  2004.        either format. The new format is a little more robust and
  2005.        easier to use. The parser also now calls separate pfutil
  2006.        functions that do the creation and configuration work. This
  2007.        will make it easier to create custom configuration routines.
  2008.  
  2009.        The configuration files now support relative pathnames.
  2010.        Cliptexture configuration files can now be created that
  2011.        don't need image cache configuration files.
  2012.  
  2013.  
  2014.        6.15.5.2  _A_c_t_i_v_e__S_u_r_f_a_c_e__D_e_f_i_n_i_t_i_o_n
  2015.  
  2016.        _l_i_b_p_f_s _n_o _l_o_n_g_e_r _e_x_i_s_t_s. You should make sure you no longer
  2017.        link with it. pfTerrain no longer exists either.  All
  2018.        PFTERRAIN_ tokens have been renamed PFASD_.  Aligning object
  2019.        to pfASD uses pfFlux and pfEngine.
  2020.  
  2021.  
  2022.            ppppffffAAAASSSSDDDDGGGGSSSSttttaaaatttteeee((((ppppffffAAAASSSSDDDD**** ____aaaassssdddd,,,, ppppffffGGGGeeeeooooSSSSttttaaaatttteeee ****ggggssss))))
  2023.  
  2024.        is now
  2025.  
  2026.  
  2027.            ppppffffAAAASSSSDDDDGGGGSSSSttttaaaatttteeeessss((((ppppffffAAAASSSSDDDD**** ____aaaassssdddd,,,, ppppffffGGGGeeeeooooSSSSttttaaaatttteeee ********ggggssss,,,, iiiinnnntttt nnnnuuuummmm))))
  2028.  
  2029.        It is important that when you port to this new api you use
  2030.        pfMalloc to allocate the array of pfGeoState pointers.
  2031.  
  2032.        So:
  2033.  
  2034.  
  2035.                ppppffffAAAASSSSDDDDGGGGSSSSttttaaaatttteeee((((aaaassssdddd,,,, ggggssss))));;;;
  2036.  
  2037.        Should become:
  2038.  
  2039.  
  2040.  
  2041.  
  2042.  
  2043.  
  2044.  
  2045.  
  2046.  
  2047.  
  2048.  
  2049.  
  2050.                                   - 32 -
  2051.  
  2052.  
  2053.  
  2054.                {{{{
  2055.                   ppppffffGGGGeeeeooooSSSSeeeetttt ********ggggssssssss;;;;
  2056.                   ggggssssssss ==== ((((ppppffffGGGGeeeeooooSSSSeeeetttt ********))))ppppffffMMMMaaaalllllllloooocccc((((ssssiiiizzzzeeeeooooffff((((ppppffffGGGGeeeeooooSSSSeeeetttt********))))****1111,,,,
  2057.                                ppppffffGGGGeeeettttSSSShhhhaaaarrrreeeeddddAAAArrrreeeennnnaaaa(((())))))));;;;
  2058.                   ggggssssssss[[[[0000]]]] ==== ggggssss;;;;
  2059.                   ppppffffAAAASSSSDDDDGGGGSSSSttttaaaatttteeeessss((((aaaassssdddd,,,, ggggssssssss,,,, 1111))));;;;
  2060.                }}}}
  2061.  
  2062.        PFTERRAIN constants have become PFASD constants pfs prefix
  2063.        has become pfASD pfsFace data structure has become pfASDFace
  2064.        and the field names have been changed to properly reflect
  2065.        the functionality.
  2066.  
  2067.        A current version of the Muligen loader is supplied to
  2068.        handle these changes
  2069.  
  2070.        New sample programs including examples of aligning features
  2071.        and moving objects to ASD geometry.
  2072.  
  2073.                /usr/share/Performer/src/pguide/libpf/C/ASD_align.c
  2074.  
  2075.        New sample program that demonstrates the pfASD data
  2076.        structure
  2077.  
  2078.                /usr/share/Performer/src/pguide/libpf/C++/simpleASD.C
  2079.  
  2080.  
  2081.        pfASD can be paged in as simle areal blocks, as handled by
  2082.        Multigen CAT feature.
  2083.  
  2084.        pfASD also supports a multi-resolution paging scheme, very
  2085.        similar to clipmap paging. An example of the construction of
  2086.        pfASD from a set of uniform elevation data  can be found in
  2087.  
  2088.                /usr/share/Performer/src/lib/libpfdu/pfdBuildASD.c
  2089.  
  2090.        Inside the same file, you can find routines that constructs
  2091.        paging ASD tiles from a fully built ASD structure. Please
  2092.        notice that the builder is for demonstration purposes
  2093.        mainly. The algorithm used is not sophisticated enough to
  2094.        provent terrain from visible morphing distortion during
  2095.        real-time fly through. The demo "yosemite" provided on 2.2
  2096.        demo CD is constructed using CAT feature in Multigen.
  2097.  
  2098.        Paging construction example can be found in
  2099.  
  2100.                /usr/share/Performer/src/pguide/libpf/C/buildarcinfo.c
  2101.                /usr/share/Performer/src/pguide/libpf/C/buildbw.c
  2102.                /usr/share/Performer/src/pguide/libpf/C/builddem.c
  2103.                /usr/share/Performer/src/pguide/libpf/C/builddted.c
  2104.  
  2105.  
  2106.  
  2107.  
  2108.  
  2109.  
  2110.  
  2111.  
  2112.  
  2113.  
  2114.  
  2115.  
  2116.                                   - 33 -
  2117.  
  2118.  
  2119.  
  2120.        Executing the command, e.g.
  2121.  
  2122.                buildbw elevation.bw bw/tile bw/config bw/page
  2123.  
  2124.        will put a set of paging tiles under the directory bw, with
  2125.        prefix "tile" as their file names. Once you decide on how
  2126.        many extra tiles to page on each LOD based on LODRange as
  2127.        well as the paging delay, you MUST process the tiles one
  2128.        more time into a fast paging binary format before feeding it
  2129.        into a paging pfASD node.
  2130.  
  2131.        The second pass paging data construction can be found in
  2132.  
  2133.                /usr/share/Performer/src/pguide/libpf/C/convasd.c
  2134.  
  2135.        For example,
  2136.  
  2137.                convasd bw/config bw/page
  2138.  
  2139.        will process the tiles.  The final step is to hand all the
  2140.        attributes defined in the config file and page file to pfASD
  2141.        by calling
  2142.  
  2143.                pfdLoadConfig(config, page);
  2144.  
  2145.  
  2146.  
  2147.        6.15.5.3  _O_p_e_n_G_L__V_e_r_t_e_x__A_r_r_a_y_s
  2148.  
  2149.        The OpenGL _V_e_r_t_e_x_A_r_r_a_y extension is supported by IRIS
  2150.        Performer as an optimized way to send formatted data to the
  2151.        graphics pipeline, reducing the host interface.
  2152.  
  2153.        Vertex arrays use a new pfGSetAttr list, PFGS_PACKED_ATTRS,
  2154.        that includes a separate copy of the vertex attribute data
  2155.        packed into a single non-indexed array.  Your vertex
  2156.        coordinates may optionally be in this packed array.  A
  2157.        sample program that demonstrates the use of vertex arrays on
  2158.        pfGeoSets is in:
  2159.  
  2160.                /usr/share/Performer/src/pguide/libpr/packedattrs.c
  2161.  
  2162.        Additionally, there is a utility traversal,
  2163.        pfuTravCreateVertArrays, that will traverse the scene graph
  2164.        and create vertex arrays for the pfGeoSets and optionally
  2165.        pfDelete the other redundant attribute arrays.  The utility
  2166.        routines used by this traversal to actually pack the
  2167.        pfGeoSet data is  pfuFillGSetVertArray().  This traversal
  2168.        can be invoked on the Perfly sample application with the -v
  2169.        # option where # is 1 or 2 to select one of two packed
  2170.        formats of with or without the vertices copied into the
  2171.  
  2172.  
  2173.  
  2174.  
  2175.  
  2176.  
  2177.  
  2178.  
  2179.  
  2180.  
  2181.  
  2182.                                   - 34 -
  2183.  
  2184.  
  2185.  
  2186.        vertex array, respectively.
  2187.  
  2188.  
  2189.        6.15.5.4  _O_p_e_n_G_L__s_p_l_i_n_e__F_o_g
  2190.  
  2191.        InfiniteReality supports the specification of a fog function
  2192.        so Spline Fog support for OpenGL has been added to IRIS
  2193.        Performer and will be available on machines that support it.
  2194.  
  2195.  
  2196.        6.15.5.5  _T_F_a_n_s
  2197.  
  2198.        IRIS Performer 2.2 supports Triangle Fans in a pfGeoSets
  2199.        when using OpenGL
  2200.  
  2201.  
  2202.        6.15.5.6  _A_s_y_n_c_h_r_o_n_o_u_s__D_y_n_a_m_i_c__D_a_t_a
  2203.  
  2204.        IRIS Performer 2.2 supports truly asynchronous dynamic data
  2205.        with _p_f_F_l_u_x.  Data for geometry attributes in pfGeoSets and
  2206.        fields in various pfNodes can be computed in fully
  2207.        asynchronous processes and store in a pfFlux buffer.  pfFlux
  2208.        will manage the the hookup, data exclusion, and frame
  2209.        management accurate book-keeping.  pfFluxes can be
  2210.        explicitly driven by _p_f_E_n_g_i_n_e_s for defining the functions
  2211.        that generate the dynamic data.
  2212.  
  2213.        pfGeoSets themselves can be fluxed and fluxed pfGeoSets can
  2214.        be given to a pfGeode directly.
  2215.  
  2216.        pfEngines can be used to control the data in a flux. A
  2217.        complete graph of pfEngines and pfFlux can be done to
  2218.        control the dynamic behavior of a database. Both pfEngines
  2219.        and pfFluxes are stored in the performer binary file format
  2220.        (pfb), even external functions used by pfEngines can be
  2221.        registers into the pfb and the right DSO will automatically
  2222.        be loaded when the pfb file will be used in Performer.
  2223.  
  2224.  
  2225.        6.15.5.7  _L_i_g_h_t__P_o_i_n_t
  2226.  
  2227.        A new light point process can be forked off and use a cpu to
  2228.        do the _p_f_L_P_o_i_n_t_S_t_a_t_e computation instead of taking time of
  2229.        the Draw Process.  The light point process is synchronous to
  2230.        the Draw process, and also support Calligraphic Light points
  2231.        when the Calligraphic Board and Projector are hooked to the
  2232.        system. To learn more about raster and calligraphic lights
  2233.        see the pfLPointState and _p_f_C_a_l_l_i_g_r_a_p_h_i_c man pages, as well
  2234.        as the pfChannel man pages to see how the light point
  2235.        process works.
  2236.  
  2237.  
  2238.  
  2239.  
  2240.  
  2241.  
  2242.  
  2243.  
  2244.  
  2245.  
  2246.  
  2247.  
  2248.                                   - 35 -
  2249.  
  2250.  
  2251.  
  2252.        6.15.5.8  _N_e_w__l_o_a_d_e_r_s
  2253.  
  2254.           +o Loaders for creating pfASD structures from elevation
  2255.             data are now include in IRIS Performer 2.2
  2256.             _l_i_b_p_f_d_b/_l_i_b_p_f_d_e_m - This loader handles a variety of the
  2257.             USGS DEM elevation data products, including the common
  2258.             7.5 minute (1:24,000) and 1 degree (1:250,000) DEM
  2259.             files.  _l_i_b_p_f_d_b/_l_i_b_p_f_d_t_e_d - This loader handles DMA
  2260.             DTED Level 1 and 2 elevation data products.
  2261.             _l_i_b_p_f_d_b/_l_i_b_p_f_a_r_c_i_n_f_o - This loader handles elevation
  2262.             data files in the simple ARC/INFO ASCII GRID export
  2263.             format.  _l_i_b_p_f_d_b/_l_i_b_p_f_e_v_t - This loader reads data in
  2264.             the temporary ".evt" binary format.
  2265.             The loaders read the elevation data from the file and
  2266.             construct an appropriate pfASD node structure.  The
  2267.             origin coordinates of the created pfASD node will be
  2268.             set to the southwest corner, zero altitude point of the
  2269.             elevation data area.  The data will be oriented in the
  2270.             XY plane for elevation data specified in planar
  2271.             coordinates (such as UTM), or oriented properly on the
  2272.             earth ellipsoid for data specified in geodetic
  2273.             coordinates (Z-axis towards North Pole, X-axis defined
  2274.             by the intersection of the prime meridian and
  2275.             equatorial planes).  Use pfdBuildASD to indicate the
  2276.             levels of detail you wish to build.  That is the last
  2277.             parameter in pfdBuildASD().
  2278.  
  2279.             The function "libpfdu/pfdBuildASD()" can be used to
  2280.             construct pfASD structures for elevation data not
  2281.             handled by the above loaders.  There are support for
  2282.             building paging tiles in pfdBuildASD(). It is not
  2283.             turned on by default. Set the PAGING constant in
  2284.             pfdBuildASD.c to 1 if you want to experiment with
  2285.             paging pfASD tiles.
  2286.  
  2287.  
  2288.           +o A VRML 2.0 loader is included. This loader is a gift
  2289.             from DrAW Computing Associates and will successfully
  2290.             the geometry and texture of many VRML2.0 files. To have
  2291.             more VRML 2.0 support, such as Routes, JAVA,
  2292.             saveToVrml, html direct access from performer, or to
  2293.             report any problem with the VRML 2.0 loader you will
  2294.             have to contact them directly at info@openworlds.com.
  2295.             See the demos under openworlds in the Friend of
  2296.             Performer 2.2 CD.  Note that VRML 1.0 files are not
  2297.             supported by this loader. Previously the case, so you
  2298.             have either to convert your VRML1.0 files to VRML2.0,
  2299.             or to explicitly name your files .iv so the inventor
  2300.             loader will be used in place of the VRML 2.0 loader.
  2301.  
  2302.  
  2303.  
  2304.  
  2305.  
  2306.  
  2307.  
  2308.  
  2309.  
  2310.  
  2311.  
  2312.  
  2313.  
  2314.                                   - 36 -
  2315.  
  2316.  
  2317.  
  2318.           +o A OpenGL Optimizer binary file loader (csb) is part of
  2319.             IRIS Performer 2.2 distribution. This allow exchange of
  2320.             files in between the two products as OpenGL Optimizer
  2321.             reads IRIS Performer binary files (pfb). Note that the
  2322.             pfb loader for Optimizer has a problem that changes all
  2323.             opaque polygons to fully transparent and vice-versa.
  2324.             This will be fixed, and a new pfb loader for OpenGL
  2325.             Optimizer will be available on the Web. (see section 4
  2326.             of release note)
  2327.  
  2328.  
  2329.  
  2330.        6.15.5.9  _C_o_p_l_a_n_a_r__g_e_o_m_e_t_r_y
  2331.  
  2332.        Layer and Decal geometry may now use the new OpenGL
  2333.        reference plane.  Reference planes may be specified on
  2334.        pfGeoSets, pfGeoStates, and in the global state.  See the
  2335.        pfGeoSet and pfDecal, and pfGeoState reference pages for
  2336.        more information.
  2337.  
  2338.  
  2339.        6.15.5.10  _T_e_x_t_u_r_e__m_a_t_r_i_c_e_s
  2340.        Texture matrices may now be specified on pfGeoStates.  See
  2341.        the pfGeoState reference page for more information.
  2342.  
  2343.  
  2344.        6.15.5.11  _T_r_a_v_e_r_s_a_l_s
  2345.        libpfutil traversal, pfuTravCompileDList, traversal for
  2346.        traversing an entire scene graph and creating display lists
  2347.        for all pfGeoSets.  This is to be used in combination with
  2348.        pfuTravDListDraw and is useful for compiling and pre-
  2349.        downloading display lists on InfiniteReality.
  2350.  
  2351.  
  2352.        6.15.5.12  _V_i_d_e_o__t_e_x_t_u_r_i_n_g
  2353.  
  2354.        There is one main sample program for video texturing:
  2355.  
  2356.           /usr/share/Performer/src/pguide/libpf/C/movietex.c
  2357.  
  2358.        a multiprocessing example.  Note that all video
  2359.        initialization, including the creation of video library
  2360.        resources, is done in the draw process, as required by the
  2361.        video library. The program has #define switches for
  2362.        compilation on IRIX 6.2 or IRIX 6.5 and supports DIVO,
  2363.        Sirius, OCTANE, and O2 video options.  Movitex.c uses
  2364.        features added in Performer 2.2: special pfTexture LOAD
  2365.        source parameters for specifying dmedia buffers or the video
  2366.        library server, path and drain, as well as the texture
  2367.        matrix that can be specified on a pfGeoState with the
  2368.        PFSTATE_TEXMAT attribute for transforming texture
  2369.  
  2370.  
  2371.  
  2372.  
  2373.  
  2374.  
  2375.  
  2376.  
  2377.  
  2378.  
  2379.  
  2380.                                   - 37 -
  2381.  
  2382.  
  2383.  
  2384.        coordinates int the proper area of a texture receiving video
  2385.        input.
  2386.  
  2387.        An old Sirius example has been retained in
  2388.        /usr/share/Performer/src/pguide/libpr/C/siriusvidtex.c.
  2389.  
  2390.  
  2391.        6.15.5.13  _T_e_x_t_u_r_e__L_O_D__o_b_j_e_c_t
  2392.  
  2393.        New pfTexLOD object for controlling LOD of textures.
  2394.        pfTexLOD is a new state attribute used to control the use of
  2395.        levels of detail of a pfTexture.  The levels of detail
  2396.        accessed can be limited by setting the LOD range and the
  2397.        computation of the current LOD value can be biased.  These
  2398.        controls are useful in conjunction with dynamic texture
  2399.        loading where the accessed levels can be limited to the
  2400.        valid levels and for artificially blurring or sharpening a
  2401.        texture.
  2402.  
  2403.  
  2404.        6.15.5.14  _N_e_w__f_a_s_t__i_m_a_g_e__f_i_l_e__f_o_r_m_a_t
  2405.  
  2406.        There is now the pfi fast image file loader to complement
  2407.        pfb.  pfi files are hardware-ready fast loading image files
  2408.        that may contain MIPmaps for textures and multiple complete
  2409.        textures.
  2410.  
  2411.        /usr/share/Performer/src/sample/pfconv.c
  2412.  
  2413.        can convert a database to use pfi files for its textures. In
  2414.        addition, there is a
  2415.  
  2416.        /usr/share/Performer/src/sample/pficonv.c
  2417.  
  2418.        for converting .rgb files to pfi files and generating
  2419.        MIPmaps.  Look at the data/town/town_ogl_pfi.pfb database.
  2420.  
  2421.  
  2422.        6.15.5.15  _p_f_C_h_a_n_n_e_l
  2423.        Here are the additional C++ member functions added in
  2424.        Performer 2.2 to those already provided in IRIS Performer
  2425.        2.1 for the pfChannel class. Each C++ function has a
  2426.        corresponding C function, and all are fully described in the
  2427.        IRIS Performer 2.2 C and C++ Reference Pages.
  2428.  
  2429.  
  2430.            ggggeeeettttFFFFrrrraaaammmmeeeePPPPVVVVCCCChhhhaaaannnn
  2431.            sssseeeettttOOOOuuuuttttppppuuuuttttVVVViiiieeeewwwwppppoooorrrrtttt
  2432.            sssseeeettttCCCCaaaalllllllliiiiggggEEEEnnnnaaaabbbblllleeee
  2433.            ggggeeeettttCCCCaaaalllllllliiiiggggEEEEnnnnaaaabbbblllleeee
  2434.            sssseeeettttCCCCaaaalllllllliiiigggg
  2435.  
  2436.  
  2437.  
  2438.  
  2439.  
  2440.  
  2441.  
  2442.  
  2443.  
  2444.  
  2445.  
  2446.                                   - 38 -
  2447.  
  2448.  
  2449.  
  2450.            ggggeeeettttCCCCaaaalllllllliiiigggg
  2451.            ggggeeeettttCCCCuuuurrrrCCCCaaaalllllllliiiigggg
  2452.            ggggeeeettttFFFFrrrreeeeeeeeBBBBiiiinnnn
  2453.            AAAASSSSDDDDAAAAttttttttaaaacccchhhh
  2454.            AAAASSSSDDDDddddeeeettttaaaacccchhhh
  2455.  
  2456.        6.15.5.16  _p_f_D_i_s_p_L_i_s_t
  2457.  
  2458.        This is the additional C++ member function added in
  2459.        Performer 2.2 to those already provided in IRIS Performer
  2460.        2.1 for the pfDispList class. This function allows the
  2461.        contents of one IRIS Performer pfDispList to be appended to
  2462.        a second pfDispList, supporting the merge of independent
  2463.        pfDispLists.  The _p_f_D_i_s_p_L_i_s_t::_a_p_p_e_n_d C++ function has a
  2464.        corresponding C function (_p_f_A_p_p_e_n_d_D_L_i_s_t), and both are fully
  2465.        described in the IRIS Performer 2.2 C and C++ Reference
  2466.        Pages.
  2467.  
  2468.  
  2469.            ggggeeeettttGGGGLLLLHHHHaaaannnnddddlllleeee
  2470.            sssseeeettttMMMMooooddddeeee
  2471.            ccccoooommmmppppiiiilllleeee
  2472.            pppprrrreeeepppprrrroooocccceeeessssssss
  2473.  
  2474.        6.15.5.17  _p_f_Q_u_e_u_e
  2475.  
  2476.        Here are the additional C++ member functions added in
  2477.        Performer 2.2 to those already provided in IRIS Performer
  2478.        2.1 for the pfQueue class.  These new functions add support
  2479.        for having a sort process that will sort the items in the
  2480.        queue.  Each C++ function has a corresponding C function,
  2481.        and all are fully described in the IRIS Performer 2.2 C and
  2482.        C++ Reference Pages.
  2483.  
  2484.  
  2485.            ggggeeeettttEEEElllleeeemmmmeeeennnnttttSSSSiiiizzzzeeee
  2486.            sssseeeettttSSSSoooorrrrttttFFFFuuuunnnncccc
  2487.            ggggeeeettttSSSSoooorrrrttttFFFFuuuunnnncccc
  2488.            ggggeeeettttSSSSoooorrrrttttMMMMooooddddeeee
  2489.            sssseeeettttIIIInnnnppppuuuuttttRRRRaaaannnnggggeeee
  2490.            ggggeeeettttIIIInnnnppppuuuuttttRRRRaaaannnnggggeeee
  2491.            ggggeeeettttOOOOuuuuttttppppuuuuttttRRRRaaaannnnggggeeee
  2492.            ggggeeeettttSSSSoooorrrrttttPPPPrrrrooooccccPPPPIIIIDDDD
  2493.            iiiinnnnsssseeeerrrrttttFFFFrrrroooonnnntttt
  2494.            aaaatttttttteeeemmmmppppttttRRRReeeemmmmoooovvvveeee
  2495.            ssssiiiiggggnnnnaaaallllAAAAllllllllSSSSeeeerrrrvvvviiiicccceeeePPPPrrrrooooccccssss
  2496.            nnnnoooottttiiiiffffyyyySSSSoooorrrrttttPPPPrrrroooocccc
  2497.  
  2498.        6.15.5.18  _p_f_I_m_a_g_e_T_i_l_e
  2499.  
  2500.        Here are the additional C++ member functions added in
  2501.  
  2502.  
  2503.  
  2504.  
  2505.  
  2506.  
  2507.  
  2508.  
  2509.  
  2510.  
  2511.  
  2512.                                   - 39 -
  2513.  
  2514.  
  2515.  
  2516.        Performer 2.2 to those already provided in IRIS Performer
  2517.        2.1 for the pfQueue class.  Each C++ function has a
  2518.        corresponding C function, and all are fully described in the
  2519.        IRIS Performer 2.2 C and C++ Reference Pages.
  2520.  
  2521.  
  2522.           sssseeeettttMMMMeeeemmmmQQQQuuuueeeeuuuueeee
  2523.           ggggeeeettttMMMMeeeemmmmQQQQuuuueeeeuuuueeee
  2524.           iiiissssLLLLooooaaaaddddiiiinnnngggg
  2525.           sssseeeettttPPPPrrrriiiioooorrrriiiittttyyyy
  2526.           ggggeeeettttPPPPrrrriiiioooorrrriiiittttyyyy
  2527.           sssseeeettttIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeee
  2528.           ggggeeeettttIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeee
  2529.           sssseeeettttTTTTiiiilllleeeeIIIInnnnddddeeeexxxx
  2530.           ggggeeeettttTTTTiiiilllleeeeIIIInnnnddddeeeexxxx
  2531.           sssseeeettttFFFFiiiilllleeeeNNNNaaaammmmeeeeFFFFuuuunnnncccc
  2532.           ggggeeeettttFFFFiiiilllleeeeNNNNaaaammmmeeeeFFFFuuuunnnncccc
  2533.           RRRReeeeaaaaddddDDDDiiiirrrreeeecccctttt
  2534.           RRRReeeeaaaaddddNNNNoooorrrrmmmmaaaallll
  2535.  
  2536.        6.15.5.19  _p_f_C_l_i_p_T_e_x_t_u_r_e
  2537.  
  2538.        Here are the additional C++ member functions added in
  2539.        Performer 2.2 to those already provided in IRIS Performer
  2540.        2.1 for the pfQueue class.  New functions deal with DTR,
  2541.        which is a tight control on how much time you want to
  2542.        allocate in the DrawProcess to dynamically load the texture
  2543.        versus drawing polygons, and control of Virtual (bigger)
  2544.        clip textures.  Each C++ function has a corresponding C
  2545.        function, and all are fully described in the IRIS Performer
  2546.        2.2 C and C++ Reference Pages.
  2547.  
  2548.  
  2549.            ggggeeeettttCCCCuuuurrrrCCCCeeeennnntttteeeerrrr
  2550.            sssseeeettttVVVViiiirrrrttttuuuuaaaallllLLLLOOOODDDDOOOOffffffffsssseeeetttt
  2551.            ggggeeeettttVVVViiiirrrrttttuuuuaaaallllLLLLOOOODDDDOOOOffffffffsssseeeetttt
  2552.            sssseeeettttNNNNuuuummmmEEEEffffffffeeeeccccttttiiiivvvveeeeLLLLeeeevvvveeeellllssss
  2553.            ggggeeeettttNNNNuuuummmmEEEEffffffffeeeeccccttttiiiivvvveeeeLLLLeeeevvvveeeellllssss
  2554.            sssseeeettttNNNNuuuummmmAAAAllllllllooooccccaaaatttteeeeddddLLLLeeeevvvveeeellllssss
  2555.            ggggeeeettttNNNNuuuummmmAAAAllllllllooooccccaaaatttteeeeddddLLLLeeeevvvveeeellllssss
  2556.            ggggeeeettttOOOOffffffffsssseeeetttt
  2557.            sssseeeettttTTTTeeeexxxxLLLLooooaaaaddddTTTTiiiimmmmeeee
  2558.            ggggeeeettttTTTTeeeexxxxLLLLooooaaaaddddTTTTiiiimmmmeeee
  2559.            sssseeeettttMMMMaaaasssstttteeeerrrr
  2560.            ggggeeeettttMMMMaaaasssstttteeeerrrr
  2561.            ggggeeeettttSSSSllllaaaavvvveeee
  2562.            sssseeeettttMMMMiiiinnnnCCCClllliiiippppSSSSiiiizzzzeeeeRRRRaaaattttiiiioooo
  2563.            ggggeeeettttMMMMiiiinnnnCCCClllliiiippppSSSSiiiizzzzeeeeRRRRaaaattttiiiioooo
  2564.            sssseeeettttDDDDTTTTRRRRMMMMooooddddeeee
  2565.            ggggeeeettttDDDDTTTTRRRRMMMMooooddddeeee
  2566.            ggggeeeettttMMMMiiiinnnnDDDDTTTTRRRRLLLLOOOODDDD
  2567.  
  2568.  
  2569.  
  2570.  
  2571.  
  2572.  
  2573.  
  2574.  
  2575.  
  2576.  
  2577.  
  2578.                                   - 40 -
  2579.  
  2580.  
  2581.  
  2582.            ggggeeeettttDDDDTTTTRRRRFFFFaaaaddddeeeeCCCCoooouuuunnnntttt
  2583.            sssseeeettttDDDDTTTTRRRRBBBBlllluuuurrrrMMMMaaaarrrrggggiiiinnnn
  2584.            ggggeeeettttDDDDTTTTRRRRBBBBlllluuuurrrrMMMMaaaarrrrggggiiiinnnn
  2585.            sssseeeettttNNNNuuuummmmEEEEffffffffeeeeccccttttiiiivvvveeeeLLLLeeeevvvveeeellllssssLLLLiiiimmmmiiiitttt
  2586.            ggggeeeettttNNNNuuuummmmEEEEffffffffeeeeccccttttiiiivvvveeeeLLLLeeeevvvveeeellllssssLLLLiiiimmmmiiiitttt
  2587.            sssseeeettttMMMMiiiinnnnLLLLOOOODDDDLLLLiiiimmmmiiiitttt
  2588.            ggggeeeettttMMMMiiiinnnnLLLLOOOODDDDLLLLiiiimmmmiiiitttt
  2589.            sssseeeettttLLLLOOOODDDDBBBBiiiiaaaassssLLLLiiiimmmmiiiitttt
  2590.            ggggeeeettttLLLLOOOODDDDBBBBiiiiaaaassssLLLLiiiimmmmiiiitttt
  2591.            sssseeeettttLLLLOOOODDDDRRRRaaaannnnggggeeee
  2592.            ggggeeeettttLLLLOOOODDDDRRRRaaaannnnggggeeee
  2593.            ggggeeeettttCCCCuuuurrrrLLLLOOOODDDDRRRRaaaannnnggggeeee
  2594.            sssseeeettttLLLLOOOODDDDBBBBiiiiaaaassss
  2595.            ggggeeeettttLLLLOOOODDDDBBBBiiiiaaaassss
  2596.            ggggeeeettttCCCCiiiirrrrLLLLOOOODDDDBBBBiiiiaaaassss
  2597.            aaaappppppppllllyyyyMMMMeeeemmmmRRRReeeegggg
  2598.            aaaappppppppllllyyyyTTTTeeeexxxxRRRReeeegggg
  2599.            uuuuppppddddaaaatttteeeeMMMMeeeemmmmTTTTeeeegggg
  2600.            uuuuppppddddaaaatttteeeeTTTTeeeexxxxRRRReeeegggg
  2601.            uuuuppppddddaaaatttteeee
  2602.            iiiinnnnvvvvaaaalllliiiiddddaaaatttteeee
  2603.            aaaappppppppllllyyyyVVVViiiirrrrttttuuuuaaaallllPPPPaaaarrrraaaammmmssss
  2604.            aaaappppppppllllyyyyCCCCeeeennnntttteeeerrrr
  2605.            iiiissssVVVViiiirrrrttttuuuuaaaallll
  2606.  
  2607.        6.16  _D_i_f_f_e_r_e_n_c_e_s _b_e_t_w_e_e_n _I_R_I_S _P_e_r_f_o_r_m_e_r _2._0 _a_n_d _p_r_e_v_i_o_u_s
  2608.              _r_e_l_e_a_s_e_s
  2609.  
  2610.        This section elucidates the changes and enhancements between
  2611.        the prior IRIS Performer 2.0 release and the even older IRIS
  2612.        Performer 1.2 release. Since all the 2.0 features are
  2613.        included in 2.2 this concerns porting from 1.2 to 2.2 as
  2614.        well.
  2615.  
  2616.        If you are new to IRIS Performer or if you have already
  2617.        converted your applications to the more recent 2.0 release
  2618.        you can skip this section, since the information contained
  2619.        here is provided merely to ease porting efforts for older
  2620.        applications. These features are also described in the the
  2621.        IRIS Performer Programming Guide.
  2622.  
  2623.  
  2624.        6.16.1  _N_e_w__F_e_a_t_u_r_e_s
  2625.  
  2626.        6.16.1.1  _S_u_p_p_o_r_t__f_o_r__O_p_e_n_G_L
  2627.        Performer 2.0 includes separate sets of libraries for
  2628.        supporting IRIS GL or OpenGL interfaces. These libraries
  2629.        have GL-dependent suffixes to indicate their type: IRIS
  2630.        GL=_igl and OpenGL=_ogl
  2631.  
  2632.            IIIIRRRRIIIISSSS GGGGLLLL:::: lllliiiibbbbppppffff____iiiiggggllll....ssssoooo
  2633.  
  2634.  
  2635.  
  2636.  
  2637.  
  2638.  
  2639.  
  2640.  
  2641.  
  2642.  
  2643.  
  2644.                                   - 41 -
  2645.  
  2646.  
  2647.  
  2648.            OOOOppppeeeennnnGGGGLLLL:::: lllliiiibbbbppppffff____ooooggggllll....ssssoooo
  2649.  
  2650.        Porting an IRIS Performer application from IRIS GL to OpenGL
  2651.        should require very little work.  There are a couple of
  2652.        isolated routine changes (see API changes below).  The main
  2653.        work will be in porting an application IRIS GL code in user
  2654.        draw callbacks and in porting the windowing and event
  2655.        handling to X.  For porting windowing code, pfWindows and
  2656.        pfPipeWindows (libpr and libpf, respectively) provide a GL
  2657.        independent windowing environment.  Libpfutil provides GL-
  2658.        input handling utilities for libpf applications using
  2659.        pfPipeWindows (pfuInitInput()).  The sample programs
  2660.        installed in
  2661.  
  2662.            ////uuuussssrrrr////sssshhhhaaaarrrreeee////PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr////ssssrrrrcccc////ppppgggguuuuiiiiddddeeee////{{{{lllliiiibbbbpppprrrr,,,,lllliiiibbbbppppffff}}}}////pppprrrrooooggggssss
  2663.  
  2664.        also demonstrate comparative X vs GL input handling.
  2665.  
  2666.        When compiling for IRIS GL, use '-DIRISGL' on the command
  2667.        line to include the IRIS GL versions of the Performer header
  2668.        files.
  2669.  
  2670.  
  2671.        6.16.1.2  _6_4_-_b_i_t__a_d_d_r_e_s_s__s_p_a_c_e__s_u_p_p_o_r_t
  2672.  
  2673.        6.16.1.3  _P_e_r_f_o_r_m_e_r__E_n_v_i_r_o_n_m_e_n_t__V_a_r_i_a_b_l_e_s__a_n_d__D_S_O_s
  2674.        Performer now robustly supports the notion of separate run-
  2675.        time file loaders as DSO's (Dynamic Shared Objects).  Thus,
  2676.        the generic utility method for opening a file now differs
  2677.        considerably - the extension of the filename is used to
  2678.        determine the name of shared object to load as well as the
  2679.        function within that shared library to call.  Two new
  2680.        environment variables exist to help locate these dynamic
  2681.        shared object libraries at run-time:
  2682.  
  2683.           +o PFLD_LIBRARY_PATH Specifies a colon separated list of
  2684.             directories where Performer should look for dynamic
  2685.             objects...
  2686.  
  2687.           +o PFHOME Specifies the root Performer directory (the root
  2688.             used to install Performer).  This is used such that
  2689.             various code in the libraries can look relative to this
  2690.             top level such as $PFHOME/usr/lib/libpfdb might be a
  2691.             location where dso's would live.  In this way a
  2692.             consistent tree structure might be maintained
  2693.             regardless of Performers PFHOME directory.  (This is
  2694.             useful when using Performer installed on another
  2695.             automounted machine for instance - setenv PFHOME
  2696.             /hosts/remote_machine/)
  2697.  
  2698.  
  2699.  
  2700.  
  2701.  
  2702.  
  2703.  
  2704.  
  2705.  
  2706.  
  2707.  
  2708.  
  2709.  
  2710.                                   - 42 -
  2711.  
  2712.  
  2713.  
  2714.        6.16.1.4  _C_+_+__A_P_I
  2715.        When compiling programs using Performer's C++ API, you need
  2716.        to directly include the class header files from
  2717.  
  2718.            ////uuuussssrrrr////iiiinnnncccclllluuuuddddeeee////PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr////pppprrrr
  2719.  
  2720.        and
  2721.  
  2722.            ////uuuussssrrrr////iiiinnnncccclllluuuuddddeeee////PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr////ppppffff....
  2723.  
  2724.        6.16.1.5  _C_o_m_p_i_l_i_n_g _P_e_r_f_o_r_m_e_r _1._2 _C++ _a_p_p_l_i_c_a_t_i_o_n_s _w_i_t_h
  2725.        _P_e_r_f_o_r_m_e_r _2._0   With Performer 2.0, compiling a Performer
  2726.        application with the C++ compiler enables the use of C++
  2727.        classes for Performer types.  Some of these Performer types
  2728.        (pfMatrix, pfVec2, pfVec3, pfVec4, pfQuat) are typedefed
  2729.        arrays when compiling with C and classes when compiling with
  2730.        C++.  Because typedefed arrays and classes differ in their
  2731.        usage, Performer applications written C++ using Performer
  2732.        1.2's C API may not compile under C++ unless Performer is
  2733.        told to revert to C types when compiling under C++.
  2734.  
  2735.        If you wish to compile existing C++ code using Performer C
  2736.        types add the line
  2737.  
  2738.            ''''####ddddeeeeffffiiiinnnneeee PPPPFFFF____CCCCPPPPLLLLUUUUSSSSPPPPLLLLUUUUSSSS____AAAAPPPPIIII 0000''''
  2739.  
  2740.        before including any Performer header files.  Note that the
  2741.        use of C types precludes the use of Performer's C++ API.
  2742.  
  2743.  
  2744.        6.16.1.6  _M_i_x_i_n_g__C_+_+__A_P_I__a_n_d__C__A_P_I__i_n__a__S_i_n_g_l_e__A_p_p_l_i_c_a_t_i_o_n
  2745.  
  2746.        Normally, when compiling under C++, the C API routines
  2747.        corresponding to member functions on a class are not exposed
  2748.        in the header files.  Applications wishing to taste the
  2749.        combined smorgasbord of both APIs should add the line
  2750.  
  2751.            ''''####ddddeeeeffffiiiinnnneeee PPPPFFFF____CCCC____AAAAPPPPIIII 1111
  2752.  
  2753.        before including any Performer header files.
  2754.  
  2755.  
  2756.        6.16.2  _L_I_B_P_R__E_n_h_a_n_c_e_m_e_n_t_s
  2757.  
  2758.        6.16.2.1  _p_f_G_e_o_S_e_t
  2759.        PFGS_POLYS for N-sided, convex polygons. Specify the number
  2760.        of sides of each polygon with pfGSetPrimLengths().
  2761.  
  2762.        pfGSetPassFilter() sets a filter which allows only specific
  2763.        pfGeoSets to be drawn, e.g., a
  2764.  
  2765.  
  2766.  
  2767.  
  2768.  
  2769.  
  2770.  
  2771.  
  2772.  
  2773.  
  2774.  
  2775.  
  2776.                                   - 43 -
  2777.  
  2778.  
  2779.  
  2780.            PPPPFFFFGGGGSSSS____NNNNOOOONNNNTTTTEEEEXXXX____GGGGSSSSEEEETTTT |||| PPPPFFFFGGGGSSSS____EEEEMMMMIIIISSSSSSSSIIIIVVVVEEEE____GGGGSSSSEEEETTTT
  2781.  
  2782.        filter will draw only non-textured, emissive pfGeoSets.
  2783.  
  2784.        pfGetGSetAttrRange() returns the number of attributes (e.g.,
  2785.        coordinates) accessed by non-indexed a pfGeoSet and the
  2786.        maximum range of indexes if the pfGeoSet is indexed.
  2787.  
  2788.        pfGeoSets can now index their pfGeoStates through a global
  2789.        table set by pfApplyGStateTable(). pfGSetGStateIndex() sets
  2790.        the value which is used to index the global table. Indexed
  2791.        pfGeoStates in conjunction with different pfGeoState tables
  2792.        allow drastically different appearances of a single database
  2793.        without duplicating geometry or the scene graph.  For
  2794.        example, a visual and infrared version of a database is
  2795.        easily supported with 2 different pfGeoState tables.
  2796.  
  2797.        pfGeoSets now accept pfCycleBuffer* as attribute lists to
  2798.        support dynamic attribute changes in a pipelined,
  2799.        multiprocessing environment.  pfCycleBuffers automatically
  2800.        manage multiple data buffers to avoid data collisions and
  2801.        ensure frame-accurate behavior of attribute changes.  This
  2802.        greatly simplifies modification of coordinates for
  2803.        sophisticated facial and skeletal animation, geometrically
  2804.        morphed level-of-detail, and special effects such as
  2805.        explosions.  Note that pfCycleBuffer nodes are obsolete with
  2806.        IRIS Performer 2.2 and that pfFlux should be used instead of
  2807.        pfCycleBuffer.
  2808.  
  2809.  
  2810.        6.16.2.2  _p_f_G_e_o_S_t_a_t_e
  2811.        pfGStateFuncs() allow pre and post callbacks on a per-
  2812.        pfGeoState basis.  The pre callback is invoked after the GL
  2813.        has been configured with the pfGeoState's state and the post
  2814.        callback is lazily invoked by the next pfGeoState
  2815.        application so the pre/post callbacks nicely bracket
  2816.        pfDrawGSet().
  2817.  
  2818.        pfGStateVal() is added for floating point values and now
  2819.        accepts PFSTATE_ALPHAREF.
  2820.  
  2821.        pfGeoSets can now index pfGeoStates (pfGSetGStateIndex())
  2822.        through pfGeoState global tables (pfApplyGStateTable()) or
  2823.        pfGeoState tables assigned to a pfChannel
  2824.        (pfChanGStateTable()) .
  2825.  
  2826.  
  2827.        6.16.2.3  _p_f_F_o_g
  2828.        pfGetFogDensity returns the density of a pfFog at a given
  2829.        range.
  2830.  
  2831.  
  2832.  
  2833.  
  2834.  
  2835.  
  2836.  
  2837.  
  2838.  
  2839.  
  2840.  
  2841.  
  2842.                                   - 44 -
  2843.  
  2844.  
  2845.  
  2846.        6.16.2.4  _p_f_L_P_o_i_n_t_S_t_a_t_e
  2847.        A new PFSTATE attribute, pfLPointState causes pfGeoSets of
  2848.        type PFGS_POINTS to be rendered as "light points", e.g.,
  2849.        runway lights, stars. Light points have perspective size
  2850.        based on range and many other features. This is a major
  2851.        enhancement and is discussed in great detail in the
  2852.        pfLPointState man page.
  2853.  
  2854.  
  2855.        6.16.2.5  _p_f_S_p_r_i_t_e
  2856.        A new kind of transform, pfSprite automatically rotates
  2857.        pfGeoSets and plain GL geometry to face the viewer.
  2858.        Different rotational constraints are possible including:
  2859.        rotate about an axis, rotate about a point.
  2860.  
  2861.  
  2862.        6.16.2.6  _p_f_T_e_x_G_e_n
  2863.        A new PFSTATE attribute, pfTexGen encapsulates the GL's
  2864.        texgen() feature which automatically generates texture
  2865.        coordinates. The Wavefront OBJ file loader in libpfdb
  2866.        provides an example of the use of this new capability. Refer
  2867.        to that source code for usage examples.
  2868.  
  2869.  
  2870.        6.16.2.7  _p_f_T_r_a_n_s_p_a_r_e_n_c_y
  2871.        pfTransparency now supports PFTR_MS_ALPHA_MASK which enables
  2872.        multisample transparency but also writes the true alpha
  2873.        value into the frame buffer instead of fully opaque alpha
  2874.        values as PFTR_MS_ALPHA does.
  2875.  
  2876.  
  2877.        6.16.2.8  _p_f_D_e_c_a_l
  2878.        When using DISPLACE type decals, LAYERS are no longer
  2879.        required to be rendered immediately after their BASES - they
  2880.        can be drawn in any order. This introduces new LAYER-
  2881.        specific tokens:  PFDECAL_LAYER_FAST, PFDECAL_LAYER_DISPLACE
  2882.        and requires specific identification of all layers after the
  2883.        first since each layer must be displaced slightly more than
  2884.        its predecessor.  The tokens PFDECAL_LAYER_1 ->
  2885.        PFDECAL_LAYER_7 are provided for layer identification.
  2886.  
  2887.  
  2888.        6.16.2.9  _p_f_C_y_c_l_e_B_u_f_f_e_r_/_p_f_C_y_c_l_e_M_e_m_o_r_y
  2889.  
  2890.        Note that pfCycleBuffer is obsolete with IRIS Performer2.2
  2891.        in favor of the pfFlux. IRIS Performer 2.0/2.1 pfCycleBuffer
  2892.        are still included in IRIS Performer 2.2.
  2893.  
  2894.        A new kind of pfMemory, pfCycleBuffer supports changing data
  2895.        in a pipelined, multiprocessing environment while
  2896.        maintaining data exclusion and frame-accurate behavior. A
  2897.  
  2898.  
  2899.  
  2900.  
  2901.  
  2902.  
  2903.  
  2904.  
  2905.  
  2906.  
  2907.  
  2908.                                   - 45 -
  2909.  
  2910.  
  2911.  
  2912.        pfCycleBuffer manages a set of buffers called pfCycleMemorys
  2913.        and "rotates" them each frame, advancing the data
  2914.        modifications cleanly down the processing pipeline. libpf
  2915.        transparently handles the buffer rotations.
  2916.  
  2917.  
  2918.        6.16.2.10  _p_f_P_o_l_y_t_o_p_e
  2919.        A pfPolytope is a set of N half spaces whose intersection
  2920.        defines a possibly semi-infinite, convex volume which is
  2921.        useful for culling and intersection testing where a tighter
  2922.        bound than a pfSphere, pfBox, pfCylinder, pfFrustum is of
  2923.        benefit.
  2924.  
  2925.  
  2926.        6.16.2.11  _p_f_G_L_O_v_e_r_r_i_d_e
  2927.        Adds the ability to force the use of a particular GL
  2928.        mechanism to implement a libpr feature.
  2929.  
  2930.  
  2931.        6.16.2.12  _p_f_N_o_t_i_f_y
  2932.        pfNotify has been enhanced with new formatting and modes
  2933.        (PFNFY_MORE).  Refer to the pfNotify man page for full
  2934.        details.
  2935.  
  2936.  
  2937.        6.16.2.13  _p_f_G_e_t_T_i_m_e
  2938.        New functions. Refer to the reference pages for further
  2939.        information.
  2940.  
  2941.            ppppffffWWWWrrrraaaappppCCCClllloooocccckkkk
  2942.  
  2943.            ppppffffCCCClllloooocccckkkkNNNNaaaammmmeeee
  2944.  
  2945.            ppppffffCCCClllloooocccckkkkMMMMooooddddeeee
  2946.  
  2947.        6.16.2.14  _W_i_n_d_o_w__S_y_s_t_e_m__R_o_u_t_i_n_e_s
  2948.        New window-system interface functions provide a single API
  2949.        for creating and managing windows that works across the IRIS
  2950.        GL, IRIS GLX Mixed Mode, and OpenGL-X environments.  Window
  2951.        system independent types have been provided to match the X
  2952.        Window System types to provide complete portability between
  2953.        the IRIS GL and OpenGL-X windowing environments.
  2954.  
  2955.  
  2956.        6.16.2.15  _p_f_Q_u_e_r_y_F_e_a_t_u_r_e_/_p_f_Q_u_e_r_y_S_y_s
  2957.        New QueryFeature routines determine the presence, absence,
  2958.        or limitations of features in the underlying graphics
  2959.        implementation, like the availability of attenuation in the
  2960.        lighting model or the availability of multiple graphics
  2961.        pipes.
  2962.  
  2963.  
  2964.  
  2965.  
  2966.  
  2967.  
  2968.  
  2969.  
  2970.  
  2971.  
  2972.  
  2973.  
  2974.                                   - 46 -
  2975.  
  2976.  
  2977.  
  2978.        The QuerySys routines determine the capacity and limitations
  2979.        of the underlying graphics implementation, like the size of
  2980.        texture memory or the number of stencil planes available.
  2981.  
  2982.  
  2983.        6.16.2.16  _p_f_T_e_x_t_u_r_e__e_x_t_e_n_s_i_o_n_s
  2984.  
  2985.        6.16.2.17  _I_n_t_e_g_r_a_t_e_d__T_e_x_t__S_u_p_p_o_r_t
  2986.        Two and Three dimensional font rendering is supported by the
  2987.        new pfFont (libpr), pfString (libpr), and pfText (libpf)
  2988.        primitives.
  2989.  
  2990.        The pfFont facility provides the capability to load fonts
  2991.        for 3-D rendering with the string drawing routines from
  2992.        pfString and pfText.  IRIS Performer uses this facility to
  2993.        provide flat, extruded, and textured-quad fonts in three
  2994.        dimensions.
  2995.  
  2996.        pfString provides a pfGeoSet like facility for encapsulating
  2997.        geometry to display a string in 3-D with attributes such as
  2998.        color, arbitrary transformation matrix, and font (see
  2999.        pfFont).
  3000.  
  3001.        A pfText node is a list of pfStrings much as a pfGeode is a
  3002.        list of pfGeoSets. The two APIs are also similar - a new
  3003.        pfText node can be created and the list of pfStrings
  3004.        attached to it can be manipulated by addition, insertion,
  3005.        removal or replacement.
  3006.  
  3007.        The best examples of these new font tools at present are
  3008.        hello.c and helloC.C, both provided in the IRIS Performer
  3009.        source directory.
  3010.  
  3011.  
  3012.        6.16.2.18  _p_f_Q_u_a_t
  3013.        A full set of quaternion utilities is defined in prmath.h
  3014.        and is documented in the pfQuat man page.
  3015.  
  3016.  
  3017.        6.16.3  _L_I_B_P_F__E_n_h_a_n_c_e_m_e_n_t_s
  3018.  
  3019.        6.16.3.1  _M_u_l_t_i_p_l_e__W_i_n_d_o_w_s__o_n__a__s_i_n_g_l_e__p_f_P_i_p_e
  3020.  
  3021.        Multiple windows can now be rendered from a single pfPipe.
  3022.        This allows a single drawing process to render to multiple
  3023.        windows on a single screen.  Libpf now requires use of the
  3024.        pfPipeWindow primitive for opening windows for pfPipes.  See
  3025.        the pfWindow and pfPipeWindow (pfConfigPWin()) reference
  3026.        pages for details.
  3027.  
  3028.  
  3029.  
  3030.  
  3031.  
  3032.  
  3033.  
  3034.  
  3035.  
  3036.  
  3037.  
  3038.  
  3039.  
  3040.                                   - 47 -
  3041.  
  3042.  
  3043.  
  3044.        6.16.3.2  _p_f_M_o_r_p_h
  3045.  
  3046.        Note that pfMorph node is obsolete in 2.2.  We recommand
  3047.        using pfFlux/pfEngines instead of pfCycleBuffer and pfMorph
  3048.        feature.
  3049.  
  3050.        pfMorph is a new group node intended for automatic morphing
  3051.        of pfGeoSet attributes: colors, normals, coordinates, and
  3052.        texture coordinates but which can morph any floating point
  3053.        values. pfMorph is triggered during the new APP traversal
  3054.        and linearly combines N source arrays into a single
  3055.        destination which is typically a pfCycleBuffer used as a
  3056.        pfGeoSet attribute array.  By modifying the source weights
  3057.        each frame, the application can produce sophisticated,
  3058.        frame-accurate effects such as facial and skeletal animation
  3059.        and morphed, geometric level-of-detail.
  3060.  
  3061.  
  3062.        6.16.3.3  _p_f_D_B_a_s_e
  3063.        The DBASE process is a new addition to the IRIS Performer
  3064.        multiprocessing family. It is similar to the ISECT process
  3065.        in that it can run asynchronously with respect to the main
  3066.        processing pipeline (APP->CULL->DRAW). Callback and trigger
  3067.        functions, pfDBaseFunc() and pfDBase() respectively, allow
  3068.        explicit control and customization of the DBASE function.
  3069.        The DBASE is intended for asynchronous database processing,
  3070.        particularly paging to and from disk when using large
  3071.        databases. Note that IRIS Performer does not provide a
  3072.        paging facility directly - rather it provides the tools
  3073.        which the application can use to implement database paging.
  3074.        Database deletions are carried out in pfDBase() and do not
  3075.        slow down the synchronous pipeline if DBASE is configured as
  3076.        a separate process.
  3077.  
  3078.  
  3079.        6.16.3.4  _p_f_B_u_f_f_e_r
  3080.        pfBuffer is the primary tool for asynchronous database
  3081.        manipulations. A pfBuffer isolates database changes to a
  3082.        given process, avoiding dangerous data collisions with other
  3083.        processes when multiprocessing.  Scene graphs built in an
  3084.        asynchronous process, such as the DBASE, do not affect the
  3085.        synchronous, real-time APP->CULL->DRAW pipeline and are
  3086.        quickly and safely merged into the main processing stream
  3087.        with pfMergeBuffer().
  3088.  
  3089.  
  3090.        6.16.3.5  _p_f_M_u_l_t_i_t_h_r_e_a_d
  3091.        pfMultithread adds a new multiprocessing dimension by
  3092.        multithreading a given IRIS Performer processing stage.
  3093.        Currently, only the CULL stage may be multithreaded such
  3094.        that thread culls a pfChannel. This is expected to be very
  3095.  
  3096.  
  3097.  
  3098.  
  3099.  
  3100.  
  3101.  
  3102.  
  3103.  
  3104.  
  3105.  
  3106.                                   - 48 -
  3107.  
  3108.  
  3109.  
  3110.        useful for MCO applications where many pfChannels per pipe
  3111.        cause the CULL stage to become a bottleneck.
  3112.  
  3113.  
  3114.        6.16.3.6  _P_F_T_R_A_V___A_P_P
  3115.        PFTRAV_APP is a new automated IRIS Performer traversal
  3116.        intended for behavior computation, event distribution and
  3117.        other application level functions. It is carried out in the
  3118.        APP process and is initiated directly by pfAppFrame() or
  3119.        automatically by pfSync(). A wrapper callback and callback
  3120.        data (pfAppFunc(), pfPassAppData()) and node callbacks and
  3121.        data (pfNodeTravFuncs(), pfNodeTravData()) provide
  3122.        application extensibility similar to that offered for the
  3123.        CULL, DRAW, and ISECT traversals.
  3124.  
  3125.  
  3126.        6.16.3.7  _p_f_C_h_a_n_D_a_t_a
  3127.        pfChannel passthrough data may be supplied by the
  3128.        application with pfChanData() rather than allocated by the
  3129.        pfChannel with pfAllocChanData().  This allows pfChannels to
  3130.        share a single passthrough data block.
  3131.  
  3132.  
  3133.        6.16.3.8  _p_f_C_h_a_n_C_u_l_l_P_t_o_p_e
  3134.        pfChanCullPtope() specifies that a pfChannel use a
  3135.        pfPolytope, rather than its viewing pfFrustum, for culling.
  3136.        This allows highly customized culling for specific
  3137.        environments where visibility can be predetermined to some
  3138.        extent, e.g., when in a room and looking through a door the
  3139.        cull volume can be shrunk to the door opening.
  3140.  
  3141.  
  3142.        6.16.3.9  _p_f_C_h_a_n_N_o_d_e_I_s_e_c_t_S_e_g_s
  3143.        pfChanNodeIsectSegs() is identical to pfNodeIsectSegs() but
  3144.        includes a pfChannel to evaluate pfLODs during the
  3145.        intersection traversal.  Thus, pfChanNodeIsectSegs()
  3146.        computes intersections with the same level-of-detail as is
  3147.        selected for rendering. This greatly simplifies operations
  3148.        such as terrain following on terrain which is modeled as
  3149.        levels-of-detail.
  3150.  
  3151.  
  3152.        6.16.3.10  _p_f_C_h_a_n_G_S_t_a_t_e_T_a_b_l_e
  3153.        pfChannels can provide a pfGeoState table which is accessed
  3154.        by indexed pfGeoSets. This simplifies the management of
  3155.        multiple views of a single database, such as infrared vs.
  3156.        out-the-window.
  3157.  
  3158.  
  3159.  
  3160.  
  3161.  
  3162.  
  3163.  
  3164.  
  3165.  
  3166.  
  3167.  
  3168.  
  3169.  
  3170.  
  3171.  
  3172.                                   - 49 -
  3173.  
  3174.  
  3175.  
  3176.        6.16.3.11  _p_f_V_i_d_e_o_R_a_t_e
  3177.        In release 1.2, IRIS Performer internally computed the rate
  3178.        of the video clock.  In 2.0, IRIS Performer now queries the
  3179.        video microcode for the video retrace rate or accepts the
  3180.        rate set by the application with pfVideoRate().
  3181.  
  3182.  
  3183.        6.16.3.12  _p_f_C_o_n_f_i_g_S_t_a_g_e
  3184.        pfStageConfigFunc() allows the specification of an
  3185.        initialization callback for each IRIS Performer processing
  3186.        stage. pfConfigStage() invokes specified initialization
  3187.        callbacks in the appropriate processes at the next
  3188.        pfFrame(). Initialization callbacks typically establish the
  3189.        initial conditions of a process. Examples include setting
  3190.        non-degrading priorities and locking processes to CPUs for
  3191.        real-time applications and downloading textures in the DRAW
  3192.        stage.
  3193.  
  3194.  
  3195.        6.16.3.13  _p_f_L_o_o_k_u_p_N_o_d_e
  3196.        pfLookupNode() extends pfFindNode by searching for a path-
  3197.        named node of a particular type, beginning at a specific
  3198.        node. This greatly simplifies finding named parts of a
  3199.        pfCloned subgraph.
  3200.  
  3201.  
  3202.        6.16.3.14  _p_f_S_c_e_n_e_G_S_t_a_t_e
  3203.        pfScenes can now reference a pfGeoState that defines the
  3204.        "global state" which may be inherited by other pfGeoStates
  3205.        within the scene.
  3206.  
  3207.  
  3208.        6.16.3.15  _p_f_G_e_t_S_C_S_M_a_t_P_t_r__a_n_d__p_f_G_e_t_D_C_S_M_a_t_P_t_r
  3209.        pfGetDCSMatPtr() returns a pointer to the pfDCS matrix for
  3210.        fast access. Likewise, pfGetSCSMatPtr() returns a pointer to
  3211.        the pfSCS matrix.
  3212.  
  3213.  
  3214.        6.16.3.16  _N_e_w__G_L_-_i_n_d_e_p_e_n_d_e_n_t__W_i_n_d_o_w_i_n_g__U_t_i_l_i_t_i_e_s
  3215.        IRIS Performer now provides utilities for opening, closing,
  3216.        and managing windows.  The same routines will manage pure
  3217.        IRIS GL windows, IRIS GL-X Mixed-Mode, and OpenGL-X windows.
  3218.        Libpf application will now use the new pfPipeWindow for
  3219.        opening IRIS Performer windows.  See the pfWindow (libpr)
  3220.        and pfPipeWindow (libpf) (pfConfigPWin()) reference pages
  3221.        for details.
  3222.  
  3223.  
  3224.        6.16.3.17  _A_P_I__C_h_a_n_g_e_s
  3225.        pfSelectCtab() is now pfApplyCtab()
  3226.        pfGetMallcoSize() is now pfGetSize()
  3227.  
  3228.  
  3229.  
  3230.  
  3231.  
  3232.  
  3233.  
  3234.  
  3235.  
  3236.  
  3237.  
  3238.                                   - 50 -
  3239.  
  3240.  
  3241.  
  3242.        pfGetHyperId() is now pfGetPipeHyperId()
  3243.  
  3244.  
  3245.        6.16.3.18  _R_e_f_e_r_e_n_c_e__C_o_u_n_t_i_n_g
  3246.        All pfObjects, including pfNodes now have a reference count.
  3247.        A pfGroup increments the reference count of all its
  3248.        children.
  3249.  
  3250.  
  3251.        6.16.3.19  _M_o_d_e__Q_u_e_r_y__S_e_m_a_n_t_i_c_s
  3252.        pfGetGStateAttr/Mode do not return the global values of
  3253.        inherited state elements. Instead NULL and -1 are returned.
  3254.        Use pfGetCurGStateAttr/Mode for 1.2 behavior.
  3255.  
  3256.  
  3257.        6.16.3.20  _V_i_d_e_o__C_l_o_c_k
  3258.        pfInitVClock() no longer starts and stops the video clock.
  3259.        Instead, use pfStart/StopVClock() to start and stop video
  3260.        interrupts. pfStart/StopVClock are only necessary for
  3261.        VGX/VGXT graphics and are ignored on other graphics.
  3262.  
  3263.  
  3264.        6.16.3.21  _p_f_P_i_p_e_S_c_r_e_e_n
  3265.        Proper multipipe operation now requires that pipes be
  3266.        assigned a screen (pfPipeScreen) before the first pfFrame().
  3267.        Otherwise, pipes will be automatically assigned a screen.
  3268.  
  3269.  
  3270.        6.16.3.22  _p_f_E_v_a_l_u_a_t_e_L_O_D
  3271.        pfEvaluateLOD() returns a floating point number indicating
  3272.        which child is selected by a given pfChannel. The fractional
  3273.        portion of the number is used for fading transitions.
  3274.  
  3275.  
  3276.        6.16.3.23  _p_f_L_O_D_S_t_a_t_e
  3277.        pfLODStates are used to specify how individual LOD's or
  3278.        groups of LODs will respond to stress and range.
  3279.        pfLODStates can either be explicitly set per LOD or set as
  3280.        an index into a list of pfLODStates provided to a pfChannel.
  3281.        Thus pfLODStates can make the same pfLOD behave differently
  3282.        in different channels as well as differently under different
  3283.        stress conditions.  pfLODStates ultimately modify the range
  3284.        and fade transition calculations made by performer when
  3285.        culling.  See pfLODState, pfLOD, and pfChannel.
  3286.  
  3287.  
  3288.        6.16.3.24  _p_f_L_O_D__e_n_h_a_n_c_e_m_e_n_t_s
  3289.        pfLODs now support per-pair transition zones for fade LOD
  3290.        See the pfLODTransition reference page.
  3291.  
  3292.        pfLODs now respond to stress by scaling LOD ranges and
  3293.  
  3294.  
  3295.  
  3296.  
  3297.  
  3298.  
  3299.  
  3300.  
  3301.  
  3302.  
  3303.  
  3304.                                   - 51 -
  3305.  
  3306.  
  3307.  
  3308.        transition zones and take a pfLODState structure to describe
  3309.        the desired stress behavior of a pfLOD. See the pfLODState
  3310.        reference page.
  3311.  
  3312.        LOD Priority Classes can be formed by the sharing of
  3313.        pfLODState structures across a set of LODs.
  3314.  
  3315.        Per-Channel LOD Priority Classes can be formed by assigning
  3316.        pfChannels with tables of pfLODStates and assigning pfLODs
  3317.        an index into these tables. See the pfChanLODAttr and
  3318.        pfLODLODStateIndex reference pages.
  3319.  
  3320.  
  3321.  
  3322.        6.16.4  _l_i_b_p_f_d_u__E_n_h_a_n_c_e_m_e_n_t_s
  3323.  
  3324.        6.16.4.1  _O_p_t_i_m_i_z_i_n_g__S_c_e_n_e__B_u_i_l_d_e_r__f_o_r__u_s_e__i_n__F_i_l_e__L_o_a_d_e_r_s
  3325.        Performer 2.0 contains a new layer of support for easily
  3326.        converting databases from external formats into performer
  3327.        runtime structures.  This new layer is called libpfdu which
  3328.        stands for library of performer database utilities.  The
  3329.        pfdBuilder contains mechanisms for completely converting
  3330.        external database formats and data into efficient IRIS
  3331.        performer structures.  The builder will take care of state
  3332.        sharing and sort your geometry by state.  Collections of
  3333.        graphics state and geometry are given to the pfdBuilder as a
  3334.        database is read in. At the end of reading a database file,
  3335.        a pfNode containing an efficient Performer representation of
  3336.        the database can be obtained.  This new API supersedes the
  3337.        previous pfuBuilder which was a simple interface for
  3338.        encapsulating geometric data into performer structures in an
  3339.        intuitive way.  This new layer of support is built on top of
  3340.        and is a superset of the previous pfuBuilder (which has now
  3341.        become the pfdGeoBuilder) that was released with Performer
  3342.        1.2.  Check out
  3343.  
  3344.            ////uuuussssrrrr////iiiinnnncccclllluuuuddddeeee////PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr////ppppffffdddduuuu....hhhh
  3345.  
  3346.        for mode settings and api for the new extended builder.
  3347.  
  3348.        libpfdu is the Performer library of database utilities.  Its
  3349.        purpose is to provide helpful functions for constructing
  3350.        optimized Performer data structures and scene graphs.  It is
  3351.        used mainly by database loaders which take an external file
  3352.        format containing 3d geometry and graphics state and load
  3353.        them into Performer optimized run-time only structures.
  3354.        Note that these utilities often prove very useful as most
  3355.        modeling tools and file formats represent their data in
  3356.        structures that correspond to the way users model data and
  3357.        these data structures are often necessarily mutually
  3358.        exclusive with effective and efficient Performer run-time
  3359.  
  3360.  
  3361.  
  3362.  
  3363.  
  3364.  
  3365.  
  3366.  
  3367.  
  3368.  
  3369.  
  3370.                                   - 52 -
  3371.  
  3372.  
  3373.  
  3374.        structures.  libpfdu contains many utilities including dso
  3375.        support for database loaders and their modes, file path
  3376.        support, etc, but the heart of libpfdu is the notion of the
  3377.        Performer database 'builder' - pfdBuilder.
  3378.  
  3379.        The builder is a tool to allow users to input/output a
  3380.        collection of geometry and graphics state in immediate mode
  3381.        fashion (similar to Open/Iris GL).  Data is inputed to the
  3382.        builder one geometric primitive at a time along with its
  3383.        corresponding graphics state.  When all of the data has been
  3384.        inputed, the user simply requests optimized Performer data
  3385.        structures which can then be used as a part of a Performer
  3386.        Scene Graph.  The builder hashs geometry into different
  3387.        'bins' based on the geometry's attribute binding types and
  3388.        associated graphics state.  It also keeps track of graphics
  3389.        state elements (textures,materials,light models, fog,etc)
  3390.        and shares state elements whenever possible.  In the end,
  3391.        the builder will create Performer 'pfGeoSets' that contain
  3392.        triangle meshes created by running the original geometry
  3393.        through the libpfdu tmeshing utility.  To go along with each
  3394.        pfGeoSet, the builder builds up a Performer pfGeoState
  3395.        (Performer's encapsulated state primitive) which has been
  3396.        optimized to share as many attributes as possible with other
  3397.        pfGeoStates being build (and possibly even with a more
  3398.        global pfChannelGState).  Having created all of these
  3399.        Performer primitives (pfGeoSets and pfGeoStates) the builder
  3400.        will place them in a Performer leaf node (pfGeode), and
  3401.        possibly even artificially create a spatial hierarchy by
  3402.        running the new database through a spatial breakup utility
  3403.        function which is also contained in libpfdu.  Note that this
  3404.        builder should also allow the user to extend the notion of a
  3405.        'graphics state' by registering callback functionality
  3406.        through builder api and then treating this
  3407.        state/functionality like any other Performer state/mode
  3408.        (although such uses of the builder are of course at least
  3409.        slightly more complicated).
  3410.  
  3411.        In short libpfdu is a collection of utilities that
  3412.        effectively act as a data funnel where users input flattened
  3413.        3d graphics information and are given in return fully
  3414.        functional and hopefully well optimized Performer run-time
  3415.        structures.
  3416.  
  3417.  
  3418.  
  3419.        6.16.5  _l_i_b_p_f_d_b__E_n_h_a_n_c_e_m_e_n_t_s
  3420.  
  3421.        6.16.5.1  _N_e_w__F_i_l_e__F_o_r_m_a_t_s   OpenInventor 2.0 file support.
  3422.        This is a completely new loader that uses OpenInventor
  3423.        traversal of the input scene graph to create the Performer
  3424.        scene graph, allowing robust conversion of all geometry.
  3425.  
  3426.  
  3427.  
  3428.  
  3429.  
  3430.  
  3431.  
  3432.  
  3433.  
  3434.  
  3435.  
  3436.                                   - 53 -
  3437.  
  3438.  
  3439.  
  3440.        AutoDesk 3DStudio file support using the 3dsftk.
  3441.  
  3442.        Side Effects Software Prisms (.poly and .bpoly) file
  3443.        support.
  3444.  
  3445.        Medit Productions Medit (.medit) file support
  3446.  
  3447.        S1000 file support, based on code from Texas Instruments.
  3448.  
  3449.        Several other formats. Look in libpfdb for the complete
  3450.        list.
  3451.  
  3452.  
  3453.        6.16.6  _S_t_r_u_c_t_u_r_a_l__C_h_a_n_g_e_s
  3454.  
  3455.        6.16.6.1  _C_l_a_s_s__s_t_r_u_c_t_u_r_e
  3456.        One of the major differences from 1.2 is that libpr is now
  3457.        written in C++ and the class tree has changed. 1.2 had both
  3458.        a prObject and pfObject - now there is a single pfObject
  3459.        which is derived from IRIS Performer's base class, pfMemory.
  3460.        There are no more pr-prefixed routines which were used for
  3461.        libpr->libpf inheritance, e.g, pfLight -> pfLightSource.
  3462.  
  3463.  
  3464.        6.16.6.2  _p_f_T_y_p_e
  3465.        IRIS Performer has changed its type system to support new,
  3466.        application-derived types. pfGetType() now returns a pfType*
  3467.        instead of a bitmask. Each IRIS Performer data type which
  3468.        has an explicit allocator (usually pfNew*()) has an
  3469.        associated pfType which is created at initialization time by
  3470.        pfInit().  The pfType corresponding to a particular class is
  3471.        returned by pfGet<*>ClassType(), e.g.,
  3472.        pfGetGroupClassType().
  3473.  
  3474.        The primary difference in 2.0 is the fact that types are no
  3475.        longer represented with bitmasks where the inheritance chain
  3476.        of a particular type is encoded in the bitmask, e.g.,
  3477.        PFTYPE_SCS == (100 | PFCLASS_SCS | PFCLASS_GROUP |
  3478.        PFCLASS_NODE), indicating that SCS is derived from pfGroup
  3479.        and pfNode.  pfType is an opaque data structure whose
  3480.        inheritance chain must be queried through pfIsOfType().
  3481.  
  3482.        Here are the old and new methods for testing an object for
  3483.        exact type equality. The 1.2 method:
  3484.  
  3485.            iiiiffff ((((ppppffffGGGGeeeettttTTTTyyyyppppeeee((((nnnnooooddddeeee)))) ======== PPPPFFFFTTTTYYYYPPPPEEEE____SSSSCCCCSSSS))))
  3486.  
  3487.        and the 2.0 methods, which are equivalent
  3488.  
  3489.            iiiiffff ((((ppppffffGGGGeeeettttTTTTyyyyppppeeee((((nnnnooooddddeeee)))) ======== ppppffffGGGGeeeettttSSSSCCCCSSSSCCCCllllaaaassssssssTTTTyyyyppppeeee(((())))))))
  3490.  
  3491.  
  3492.  
  3493.  
  3494.  
  3495.  
  3496.  
  3497.  
  3498.  
  3499.  
  3500.  
  3501.  
  3502.                                   - 54 -
  3503.  
  3504.  
  3505.  
  3506.            iiiiffff ((((ppppffffIIIIssssEEEExxxxaaaaccccttttTTTTyyyyppppeeee((((nnnnooooddddeeee,,,, ppppffffGGGGeeeettttSSSSCCCCSSSSCCCCllllaaaassssssssTTTTyyyyppppeeee(((())))))))))))
  3507.  
  3508.        Here are the old and new methods for testing an object for
  3509.        derivation from a give type. The 1.2 method:
  3510.  
  3511.            iiiiffff ((((ppppffffGGGGeeeettttTTTTyyyyppppeeee((((nnnnooooddddeeee)))) &&&& PPPPFFFFCCCCLLLLAAAASSSSSSSS____GGGGRRRROOOOUUUUPPPP))))
  3512.  
  3513.        and the 2.0 method
  3514.  
  3515.            iiiiffff ((((ppppffffIIIIssssOOOOffffTTTTyyyyppppeeee((((nnnnooooddddeeee,,,, ppppffffGGGGeeeettttGGGGrrrroooouuuuppppCCCCllllaaaassssssssTTTTyyyyppppeeee(((())))))))))))
  3516.  
  3517.        Special care should be taken when porting to the new type
  3518.        API.
  3519.  
  3520.  
  3521.        6.16.7  _C_h_a_n_g_e_s__i_n__l_i_b_p_r
  3522.  
  3523.        6.16.7.1  _D_e_f_a_u_l_t__E_n_a_b_l_e_s
  3524.        PFEN_TEXTURE, PFEN_LIGHTING, PFEN_FOG are no longer enabled
  3525.        by default.  Databases created with loaders that assumed
  3526.        specific global defaults, e.g., pfEnable(PFEN_TEXTURE) will
  3527.        be rendered improperly. All IRIS Performer loaders shipped
  3528.        with 2.0 create pfGeoStates that assume the global default
  3529.        is the same as that set by pfBasicState(), i.e., everything
  3530.        is OFF.
  3531.  
  3532.  
  3533.        6.16.7.2  _L_i_n_e__W_i_d_t_h__a_n_d__P_o_i_n_t__S_i_z_e
  3534.        pfGeoSets with linewidth/pointsize of <= 0 will not set
  3535.        linewidth or pointsize but will inherit it through the GL.
  3536.  
  3537.  
  3538.        6.16.7.3  _A_l_p_h_a__R_e_f_e_r_e_n_c_e__V_a_l_u_e
  3539.        The PFSTATE_ALPHAREF state element has changed from an
  3540.        integer in the range 0-255 to a float in the range 0-1 and
  3541.        is now set on pfGeoStates with the new routine, pfGStateVal.
  3542.        A warning will be generated if set through pfGStateMode.
  3543.  
  3544.  
  3545.        6.16.7.4  _D_e_c_a_l__I_m_p_l_e_m_e_n_t_a_t_i_o_n
  3546.        pfDecal no longer sets zwritemask to 0 when drawing
  3547.        displaced layers.  This allows layers to be drawn separately
  3548.        from their bases, enabling improved sorting by graphics
  3549.        mode.
  3550.  
  3551.  
  3552.        6.16.7.5  _M_a_t_h__F_u_n_c_t_i_o_n_s
  3553.        pfXformPt3/Vec3 previously considered the last column of the
  3554.        matrix and divided by the homogeneous coordinate, w. The new
  3555.        pfXformPt3/Vec3 are much faster and treats the pfMatrix as a
  3556.        4x3 matrix.  The old behavior is now accessed through the
  3557.  
  3558.  
  3559.  
  3560.  
  3561.  
  3562.  
  3563.  
  3564.  
  3565.  
  3566.  
  3567.  
  3568.                                   - 55 -
  3569.  
  3570.  
  3571.  
  3572.        new pfFullXformPt3/Vec3 routines.
  3573.  
  3574.        pfInvertMat is now named pfInvertFullMat but a #define
  3575.        ensures 1.2 compatibility.
  3576.  
  3577.        pfMakeRotOntoMat is obsoleted in favor of the much faster
  3578.        pfMakeVecRotVecMat which assumes normalized input vectors.
  3579.  
  3580.  
  3581.        6.16.7.6  _F_r_u_s_t_u_m__S_p_e_c_i_f_i_c_a_t_i_o_n
  3582.        pfFrustAspect is no longer persistent. In 1.2, automatic
  3583.        frustum calculation (e.g. PFFRUST_CALC_HORIZ) was always in
  3584.        effect once set. In 2.0, pfFrustAspect recomputes the
  3585.        frustum only at time of invocation.
  3586.  
  3587.  
  3588.        6.16.8  _C_h_a_n_g_e_s__i_n__l_i_b_p_f
  3589.  
  3590.        6.16.8.1  _D_e_f_a_u_l_t__E_n_a_b_l_e_s
  3591.        PFEN_TEXTURE, PFEN_LIGHTING, PFEN_FOG are no longer enabled
  3592.        by default.  Databases created with loaders that assumed
  3593.        specific global defaults, e.g., pfEnable(PFEN_TEXTURE) will
  3594.        be rendered improperly. All IRIS Performer loaders shipped
  3595.        with 2.0 create pfGeoStates which assume the global default
  3596.        is the same as that set by pfBasicState(), i.e., everything
  3597.        is OFF. To achieve 1.2 behavior with 1.2 loaders, call the
  3598.        following in the DRAW process after the window is opened:
  3599.  
  3600.            ppppffffEEEEnnnnaaaabbbblllleeee((((PPPPFFFFEEEENNNN____LLLLIIIIGGGGHHHHTTTTIIIINNNNGGGG))));;;;
  3601.  
  3602.            ////**** OOOOnnnnllllyyyy oooonnnn IIIInnnnffffiiiinnnniiiitttteeeeRRRReeeeaaaalllliiiittttyyyy////RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee////IIIImmmmppppaaaacccctttt////VVVVGGGGXXXXTTTT////VVVVGGGGXXXX ****////
  3603.            ppppffffEEEEnnnnaaaabbbblllleeee((((PPPPFFFFEEEENNNN____TTTTEEEEXXXXTTTTUUUURRRREEEE))));;;;
  3604.  
  3605.            ppppffffEEEEnnnnaaaabbbblllleeee((((PPPPFFFFEEEENNNN____FFFFOOOOGGGG))));;;;
  3606.  
  3607.        6.16.8.2  _M_u_l_t_i_-_c_h_a_n_n_e_l__f_o_g__a_n_d__l_i_g_h_t_i_n_g__c_o_n_s_i_s_t_e_n_c_y
  3608.        pfChannels now encode rotational offsets (pfChanViewOffsets)
  3609.        in the ModelView instead of the Projection matrix.
  3610.        Consequently, fog always matches across adjacent pfChannels
  3611.        but for proper lighting, a local viewer lighting model is
  3612.        required (pfLModelLocal).
  3613.  
  3614.  
  3615.        6.16.8.3  _T_y_p_e__i_n_h_e_r_i_t_a_n_c_e
  3616.        Multiple inheritance through the C API is gone. Previously,
  3617.        pfChannels could use pfFrustum API, e.g.,
  3618.        pfMakePerspFrust(chan,...) pfFrameStats could use pfStats
  3619.        API, and pfLightSources could use pfLight API, e.g.,
  3620.        pfLightPos(lsource...). Additional routines are now provided
  3621.        to maintain the same functionality without the complexities
  3622.        of multiple inheritance. The new routines name are simply
  3623.  
  3624.  
  3625.  
  3626.  
  3627.  
  3628.  
  3629.  
  3630.  
  3631.  
  3632.  
  3633.  
  3634.                                   - 56 -
  3635.  
  3636.  
  3637.  
  3638.        the old routines where the "base" class name is replaced
  3639.        with the "derived" class name. For example, pfMakePerspFrust
  3640.        becomes pfMakePerspChan and pfLightPos becomes pfLSourcePos.
  3641.        Comprehensive tables illustrating the correspondence between
  3642.        routine names are found in pfChannel, pfFrameStats, and
  3643.        pfLightSource man pages.
  3644.  
  3645.  
  3646.        6.16.8.4  _F_r_u_s_t_u_m__S_p_e_c_i_f_i_c_a_t_i_o_n
  3647.        Customizing a viewing frustum with pfMakePerspChan or
  3648.        pfMakeOrthoChan now disables the automatic viewport aspect
  3649.        ratio matching feature of pfChannel (pfChanAutoAspect).
  3650.  
  3651.  
  3652.        6.16.8.5  _A_P_I__C_h_a_n_g_e_s
  3653.        pfChanCullFunc and pfChanDrawFunc are now subsumed by
  3654.        pfChanTravFunc.
  3655.  
  3656.        pfStageConfigFunc() and pfConfigStage() replace the now
  3657.        obsolete pfInitPipe().
  3658.  
  3659.  
  3660.        6.16.8.6  _B_u_g__f_i_x
  3661.        PFPHASE_FLOAT and PFPHASE_LOCK now work in single process
  3662.        mode.
  3663.  
  3664.  
  3665.        6.16.8.7  _p_f_S_w_i_t_c_h__s_e_m_a_n_t_i_c_s
  3666.        pfSwitchVal() used to determine the validity of the switch
  3667.        value which was problematic if no children had been added to
  3668.        the pfSwitch yet. The validity check is now deferred to
  3669.        individual traversal routines.
  3670.  
  3671.  
  3672.        6.16.8.8  _p_f_D_a_t_a_P_o_o_l_s
  3673.        When Performer shared memory has been created, pfDataPools
  3674.        are now positioned in the virtual address space so that
  3675.        conflicts are less likely to arise.  Such conflicts were a
  3676.        frequent cause of failures of pfAttachDPool.  Deleting a
  3677.        data pool now detaches it from the address space.
  3678.  
  3679.  
  3680.        6.16.8.9  _p_f_P_a_r_t_i_t_i_o_n_s
  3681.        Allow better specification of the spacing and positioning of
  3682.        the spatial partition to reduce construction time. They also
  3683.        work now.
  3684.  
  3685.  
  3686.        6.16.8.10  _O_t_h_e_r__C_h_a_n_g_e_s
  3687.  
  3688.  
  3689.  
  3690.  
  3691.  
  3692.  
  3693.  
  3694.  
  3695.  
  3696.  
  3697.  
  3698.  
  3699.  
  3700.                                   - 57 -
  3701.  
  3702.  
  3703.  
  3704.        6.16.8.11  _E_l_i_m_i_n_a_t_i_o_n__o_f__m_u_l_t_i_p_l_e__i_n_h_e_r_i_t_a_n_c_e
  3705.        The CAPI inheritance of pfChannel from pfFrustum,
  3706.        pfLightSource from pfLight and pfFrameStats from pfStats has
  3707.        been removed.  API has been added on the formerly derived to
  3708.        duplicate the functionality of the former base class, e.g.
  3709.        pfApplyFrust(chan) -> pfApplyChan(chan).
  3710.  
  3711.  
  3712.        6.16.8.12  _L_i_g_h_t__M_o_d_e_l__A_t_t_e_n_u_a_t_i_o_n__v_s__L_i_g_h_t__A_t_t_e_n_u_a_t_i_o_n
  3713.        IRIS GL: Light Attenuation is on the pfLightModel
  3714.  
  3715.            vvvvooooiiiidddd ppppffffLLLLMMMMooooddddeeeellllAAAAtttttttteeeennnn((((ppppffffLLLLiiiigggghhhhttttMMMMooooddddeeeellll**** llllmmmm,,,,
  3716.                ffffllllooooaaaatttt aaaa0000,,,, ffffllllooooaaaatttt aaaa1111,,,, ffffllllooooaaaatttt aaaa2222))));;;;
  3717.  
  3718.            vvvvooooiiiidddd ppppffffGGGGeeeettttLLLLMMMMooooddddeeeellllAAAAtttttttteeeennnn((((ppppffffLLLLiiiigggghhhhttttMMMMooooddddeeeellll**** llllmmmm,,,,
  3719.                ffffllllooooaaaatttt**** aaaa0000,,,, ffffllllooooaaaatttt**** aaaa1111,,,, ffffllllooooaaaatttt**** aaaa2222))));;;;
  3720.  
  3721.        OpenGL: Light Attenuation is on the pfLight
  3722.  
  3723.            vvvvooooiiiidddd ppppffffLLLLiiiigggghhhhttttAAAAtttttttteeeennnn((((ppppffffLLLLiiiigggghhhhtttt**** lllltttt,,,,
  3724.                ffffllllooooaaaatttt aaaa0000,,,, ffffllllooooaaaatttt aaaa1111,,,, ffffllllooooaaaatttt aaaa2222))));;;;
  3725.  
  3726.            vvvvooooiiiidddd ppppffffGGGGeeeettttLLLLiiiigggghhhhttttAAAAtttttttteeeennnn((((ppppffffLLLLiiiigggghhhhtttt**** lllltttt,,,,
  3727.                ffffllllooooaaaatttt**** aaaa0000,,,, ffffllllooooaaaatttt**** aaaa1111,,,, ffffllllooooaaaatttt**** aaaa2222))));;;;
  3728.  
  3729.        6.16.8.13  _p_f_A_l_p_h_a_F_u_n_c__n_o_w__t_a_k_e_s__a__f_l_o_a_t__f_o_r__r_e_f
  3730.  
  3731.            wwwwaaaassss:::: vvvvooooiiiidddd ppppffffAAAAllllpppphhhhaaaaFFFFuuuunnnncccc((((iiiinnnntttt rrrreeeeffff,,,, iiiinnnntttt ffffuuuunnnncccc))));;;;
  3732.  
  3733.            nnnneeeewwww:::: vvvvooooiiiidddd ppppffffAAAAllllpppphhhhaaaaFFFFuuuunnnncccc((((ffffllllooooaaaatttt rrrreeeeffff,,,, iiiinnnntttt ffffuuuunnnncccc))));;;;
  3734.  
  3735.        6.16.8.14  _p_f_G_e_t_A_l_p_h_a_F_u_n_c__n_o_w__r_e_t_u_r_n_s__a__f_l_o_a_t__f_o_r__r_e_f
  3736.  
  3737.            wwwwaaaassss:::: vvvvooooiiiidddd ppppffffGGGGeeeettttAAAAllllpppphhhhaaaaFFFFuuuunnnncccc((((iiiinnnntttt ****rrrreeeeffff,,,, iiiinnnntttt ****ffffuuuunnnncccc))));;;;
  3738.  
  3739.            nnnneeeewwww:::: vvvvooooiiiidddd ppppffffGGGGeeeettttAAAAllllpppphhhhaaaaFFFFuuuunnnncccc((((ffffllllooooaaaatttt ****rrrreeeeffff,,,, iiiinnnntttt ****ffffuuuunnnncccc))));;;;
  3740.  
  3741.        6.16.8.15  _p_f_G_S_t_a_t_e_M_o_d_e__a_n_d__p_f_G_e_t_G_S_t_a_t_e_M_o_d_e
  3742.        pf{Get}GStateMode can no longer accept the PFSTATE_ALPHAREF
  3743.        token.  Use
  3744.  
  3745.            ppppffffGGGGSSSSttttaaaatttteeeeVVVVaaaallll((((ggggssssttttaaaatttteeee,,,, PPPPFFFFSSSSTTTTAAAATTTTEEEE____AAAALLLLPPPPHHHHAAAARRRREEEEFFFF,,,, vvvvaaaallll))));;;;
  3746.  
  3747.        6.16.8.16  _p_f_L_i_g_h_t_C_o_l_o_r__a_n_d__p_f_G_e_t_L_i_g_h_t_C_o_l_o_r
  3748.        pfLightColor and pfGetLightColor now take arguments to
  3749.        specify which color.
  3750.  
  3751.            wwwwaaaassss:::: ppppffffLLLLiiiigggghhhhttttAAAAmmmmbbbbiiiieeeennnntttt aaaannnndddd ppppffffGGGGeeeettttLLLLiiiigggghhhhttttAAAAmmmmbbbbiiiieeeennnntttt aaaarrrreeee oooobbbbssssoooolllleeeetttteeee....
  3752.  
  3753.            nnnneeeewwww:::: vvvvooooiiiidddd ppppffffLLLLiiiigggghhhhttttCCCCoooolllloooorrrr((((ppppffffLLLLiiiigggghhhhtttt**** lllltttt,,,, iiiinnnntttt wwwwhhhhiiiicccchhhh,,,,
  3754.                    ffffllllooooaaaatttt rrrr,,,, ffffllllooooaaaatttt gggg,,,, ffffllllooooaaaatttt bbbb))));;;;
  3755.  
  3756.  
  3757.  
  3758.  
  3759.  
  3760.  
  3761.  
  3762.  
  3763.  
  3764.  
  3765.  
  3766.                                   - 58 -
  3767.  
  3768.  
  3769.  
  3770.            nnnneeeewwww:::: vvvvooooiiiidddd ppppffffGGGGeeeettttLLLLiiiigggghhhhttttCCCCoooolllloooorrrr((((ppppffffLLLLiiiigggghhhhtttt**** lllltttt,,,, iiiinnnntttt wwwwhhhhiiiicccchhhh,,,,
  3771.                    ffffllllooooaaaatttt**** rrrr,,,, ffffllllooooaaaatttt**** gggg,,,, ffffllllooooaaaatttt**** bbbb))));;;;
  3772.  
  3773.        6.16.8.17  _p_f_I_n_i_t_G_f_x
  3774.        pfInitGfx() has changed API, location and behavior:
  3775.  
  3776.            wwwwaaaassss:::: vvvvooooiiiidddd ppppffffIIIInnnniiiittttGGGGffffxxxx((((ppppffffPPPPiiiippppeeee ****pppp))));;;;
  3777.  
  3778.            nnnneeeewwww:::: ppppffffIIIInnnniiiittttGGGGffffxxxx((((vvvvooooiiiidddd))));;;;
  3779.  
  3780.        pfInitGfx() should now be used to initialize all pfWindows
  3781.        and pfPipeWindows.
  3782.  
  3783.  
  3784.        6.16.8.18  _p_f_I_n_i_t_G_L_X_G_f_x
  3785.        pfInitGLXGfx(pfPipe *) has been removed. Use the
  3786.        pfPipeWindow utilities.
  3787.  
  3788.  
  3789.        6.16.8.19  _p_f_G_e_t_P_i_p_e_W_i_n__a_n_d__p_f_G_e_t_P_i_p_e_G_L_X_W_i_n_s
  3790.        pfGetPipeWin and pfGetPipeGLXWins have been removed. There
  3791.        is now pfGetPipePWin() to support this functionality.
  3792.  
  3793.  
  3794.        6.16.8.20  _p_f_I_n_i_t_P_i_p_e
  3795.        pfInitPipe() is obsoleted in favor of pfStageConfigFunc()
  3796.        and pfConfigStage().  pfInitPipe() no longer is used to
  3797.        create windows.  Use pfConfigPWin for a window
  3798.        initialization callback.  Use pfConfigStage for initializing
  3799.        (or later re-configuring) the CULL or DRAW processes
  3800.        (stages) for a given pipe.
  3801.  
  3802.  
  3803.        6.16.8.21  _p_f_G_e_t_P_i_p_e_O_r_i_g_i_n
  3804.        pfGetPipeOrigin() has been removed.  Use pfGetWinOrigin() or
  3805.        pfGetPWinOrigin() to get the size of a pfWindow or
  3806.        pfPipeWindow respectively.
  3807.  
  3808.  
  3809.        6.16.8.22  _p_f_G_e_t_P_i_p_e_S_i_z_e
  3810.        pfGetPipeSize() now returns the screen size of a pfPipe. Use
  3811.        pfGetWinSize() or pfGetPWinSize() to get the size of a
  3812.        pfWindow or pfPipeWindow respectively.
  3813.  
  3814.  
  3815.        6.16.8.23  _p_f_u_W_i_d_g_e_t_F_u_n_c__r_e_n_a_m_e_d
  3816.        pfuWidgetFunc() is now pfuWidgetActionFunc().
  3817.  
  3818.  
  3819.  
  3820.  
  3821.  
  3822.  
  3823.  
  3824.  
  3825.  
  3826.  
  3827.  
  3828.  
  3829.  
  3830.  
  3831.  
  3832.                                   - 59 -
  3833.  
  3834.  
  3835.  
  3836.        6.16.8.24  _p_f_u_E_n_a_b_l_e_P_a_n_e_l
  3837.        pfuEnablePanel() no longer takes an enable argument.
  3838.        Instead, pfuPanels are enabled/disabled with
  3839.        pfuEnablePanel() and pfuDisablePanel() respectively.
  3840.  
  3841.  
  3842.        6.16.8.25  _p_f_u_G_e_t_P_a_n_e_l_S_i_z_e
  3843.        pfuGetPanelSize now follows standard convention of (xo, yo,
  3844.        xs, ys) parameter ordering.
  3845.  
  3846.            wwwwaaaassss:::: ppppffffuuuuGGGGeeeettttPPPPaaaannnneeeellllSSSSiiiizzzzeeee((((ppppffffuuuuPPPPaaaannnneeee ****pppp,,,,
  3847.                     iiiinnnntttt ****xxxxoooo,,,, iiiinnnntttt ****xxxxssss,,,, iiiinnnntttt ****yyyyoooo,,,, iiiinnnntttt ****yyyyssss))));;;;
  3848.  
  3849.            nnnneeeewwww:::: ppppffffuuuuGGGGeeeettttPPPPaaaannnneeeellllOOOOrrrrggggSSSSiiiizzzzeeee((((ppppffffuuuuPPPPaaaannnneeee ****pppp,,,,
  3850.                     iiiinnnntttt ****xxxxoooo,,,, iiiinnnntttt ****yyyyoooo,,,, iiiinnnntttt ****xxxxssss,,,, iiiinnnntttt ****yyyyssss))));;;;
  3851.  
  3852.        6.16.8.26  _p_f_I_n_i_t_P_W_i_n
  3853.        pfInitPWin is now pfConfigPWin
  3854.  
  3855.  
  3856.  
  3857.  
  3858.  
  3859.  
  3860.  
  3861.  
  3862.  
  3863.  
  3864.  
  3865.  
  3866.  
  3867.  
  3868.  
  3869.  
  3870.  
  3871.  
  3872.  
  3873.  
  3874.  
  3875.  
  3876.  
  3877.  
  3878.  
  3879.  
  3880.  
  3881.  
  3882.  
  3883.  
  3884.  
  3885.  
  3886.  
  3887.  
  3888.  
  3889.  
  3890.  
  3891.  
  3892.  
  3893.  
  3894.  
  3895.